Net-to-Net Connections are the most common connection type for IPSec. They connect two networks securely and transparently with each other over the Internet.
IPFire supports the following features:
- Authentication using certificates and PSK
- Classic IPSec and routed connections using GRE/VTI
- Tunnel and Transport mode
Prerequisites
In order to set up an IPSec VPN, both systems need to be able to talk to each other over a public IPv4 address on both sides. IPSec uses UDP/500, UDP/4500 and ESP which will automatically be opened on the Firewall when you setup the connection on the GUI. A static IPv4 address eases the setup but dynamic DNS hostnames are supported, too.
- GUI access to both IPFires
- Shell access for VTI connections with masquerading
- both IPFires need to be available with a public IPv4 IP address
Creating a new Classic connection
Start creating a new connection by clicking on "Add" and select "Net-to-Net Virtual Private Network".
On the next page, choose a name for your connection.
Then, select the local IP address you would like to use for this connection. Enter the remote peer address which could be their hostname or a static IP address.
Then, you will have to decide which networks you want to connect with each other. The default for the local site is the GREEN network. The remote network cannot overlap with any local networks and you can enter multiple networks as a comma-separated list.
Filling in the IDs depends on the connection type you are choosing.
Certificates or PSK?
Connections authenticated using certificates are more robust against brute-force attacks and should be preferred over pre-shared keys. This does not have any effect on the throughput of the VPN.
Certificates
Connections with certificates are very easy to set up. All it takes is the host and root certificate of the peer.
The root certificate needs to be loaded into IPFire on the main configuration page before the connection is being created and will act as a trust anchor for the host certificate.
The host certificate will be uploaded when the connection is being created and IPFire will ask the peer to present the same certificate. To do that, select "Upload a certificate" and upload the file. If the peer holds the secret key for the host certificate, the connection is authenticated.
The ID fields at the top section of the page should be left empty.
Step-by-step
- download the root and the host certificate of both IPFire, e.g. RootCertLEFT, RootCertRIGHT, HostCertLEFT, HostCertRIGHT
- import CertLEFT on the right IPFire
- import CertRIGHT on the left IPFire
- Configure the VPN on the right IPFire, upload HostCertLEFT
- Configure the VPN on the left IPFire, upload HostCertRIGHT
PSK
Connections with PSKs are very common and set up with only three settings:
- You will need to generate a pre-shared-key that is strong enough to not be guessed. It is recommended to at least use a 32 character long key. The key must not contain the characters comma
,
or a single quotation mark?
. - Since the PSK is not enough to identify the connection in case of multiply connections using PSK authentication, you will need to fill in the "Local ID" and "Remote ID" fields. There are no restrictions for this, the pair must only be unique across all connections you have and must match with the settings of the peer. You can use:
- Any ASCII-string that starts with an
@
. It is common to use the hostname (e.g.@trucking.ipfire-at-home.com
) - Some vendors automatically fill in the IP addresses of both peers
- Any ASCII-string that starts with an
Check the classic tunnel
After clicking "Save", the connection should come straight up. You can try to ping a system on the remote network to verify that is successfully transmitting data.
VTI
VTI connections do not create routes nor firewall rules in first instance but just a tunnel with a router/next hop on each side. It's then up to you to configure routing correctly through the tunnel and setup the correct firewall rules to either allow traffic or even masquerade with SNAT. The instructions are based on an example.
Traffic from for example a ping from GREEN LEFT (172.23.0.5) to ORANGE RIGHT (192.168.101.20) will flow like this
PING: 172.23.0.5 -> 172.23.0.1 -> 192.168.10.98 -> 192.168.10.97 -> 192.168.101.1 -> 192.168.101.20
and the corresponding
PONG: 192.168.101.20 -> 192.168.101.1 -> 192.168.10.97 -> 192.168.10.98 -> 172.23.0.1 -> 172.23.0.5
VTI routing network
Subnet 192.168.10.96/29
Network 192.168.10.97
Broadcast 192.168.10.103
LEFT/local
Local IPFire in GREEN network 172.23.0.1
Local GREEN network 172.23.0.0/16
Local ORANGE network 172.22.0.0/16
Host/FQDN vpn.otherexample.net
Local ID @vpn.otherexample.net
Router/Hop (IP address/Subnet Mask) 192.168.10.98/29
RIGHT/remote
Local IPFire in GREEN network 192.168.100.1
Local GREEN network 192.168.100/24
Local ORANGE network 192.168.101/24
Host/FQDN vpn.example.net
Local ID @vpn.example.net
Router/Hop (IP address/Subnet Mask) 192.168.10.97/29
Create a VTI interface
Create the VPN connection as usual, but
- use
0.0.0.0/0
for remote subnet and local subnet - use hostnames of each side as ID
- use
VTI
as Interface - use a small network (/29) and assign an IP address from the network to each side of the VPN - those are your next hops
Setup routing
When the tunnel is up, there is still no traffic flowing since neither side knows how to route it. Traffic needs to be routed through the VTI subnet. Traffic from LEFT to RIGHT needs to hop over 192.168.10.97
and traffic from RIGHT to LEFT needs to hop over 192.168.10.98
. Even though the subnet on the LEFT could be written as 172.22.0.0/25 and the subnet on the RIGHT could be written as 192.168.100.0/23 this example will split them to emphasize the possible use of non combine-able subnets (otherwise you could just use the classic VPN w/o routing)
LEFT
On the LEFT IPFire under Network / Static Routes
setup
Host IP address / Network 192.168.100.0/24
Gateway 192.168.10.97
and
Host IP address / Network 192.168.101.0/24
Gateway 192.168.10.97
Your routing table should now look like this:
Please note: the VPN connection is the second VTI VPN connection on the IPFire used, that's why you see Interface
vti2
. If it would be the first connection the interface will be vti1
.
RIGHT
On the RIGHT IPFire you need a similar setting but with the other "router" in your VTI subnet.
Under Network / Static Routes
setup
Host IP address / Network 172.22.0.0/16
Gateway 192.168.10.98
and
Host IP address / Network 172.23.0.0/16
Gateway 192.168.10.98
You can extend this to as many subnets you want to route.
Firewall rules
The last step is to setup firewall rules. Depending on your configuration and the Firewall configuration on the other side you might want to masquerade/SNAT traffic from one of the sides. This way, only one single IP needs to be allowed, but you also loose the ability to see the correct source IP.
without SNAT/masquerading
Under Firewall / Firewall Rules
setup create a new rule
Source IPSec networks: EXAMPLE
Destination Standard networks: ANY
Protocol All
Firewall ACCEPT
Repeat the settings on the other IPFire.
You might want to further limit access using rate or concurrent connection limits or even limit access to certain protocols or hosts using Firewall Groups.
With SNAT
The settings with SNAT are the same, except that you
Use Network Address Translation (NAT) IPSec networks: EXAMPLE
Source NAT New source IP address: GREEN (172.23.250.1)
Masquerading
Assuming LEFT accepts traffic from the IPSec network, but RIGHT only accepts traffic from the VTI network (192.168.10.96/29) you need to masquerade traffic to come from the VTI router (192.168.10.98). This setting cannot be accomplished on the GUI, you need shell access to IPFire (local or SSH).
On the shell create two additional iptables rules:
iptables -t nat -A CUSTOMPOSTROUTING -s 172.23.0.0/16 -o vti2 -j MASQUERADE
iptables -t nat -A CUSTOMPOSTROUTING -s 172.22.0.0/16 -o vti2 -j MASQUERADE
Please note: you need to use the same Interface the routing table shows you for this connection, in this case vti2
. You can extend those networks to the subnets available on the LEFT.
You can verify the settings under Firewall / iptables
. Choose CUSTOMPOSTROUTING under IPTable Network Address Translation and press update.
If you see traffic (pkts/bytes) your tunnel, routing settings and firewall rules work!
Additional information
https://community.ipfire.org/t/ipfire-ipsec-net-to-net-set-up/6971/2
https://community.ipfire.org/t/ipsec-net-to-net-how-route-traffic-over-the-tunnel/6470/7