4

I'm using OpenSWAN to set up a net-to-net VPN tunnel. I have succeeded in configuring a test scenario as follows:

test net-to-net scenario

About test and test2:

  • they are Ubuntu 12.04 virtual machines created using ubuntu-vm-builder
  • they use bridged networking to the host's physical ethernet (the 192.168.0.0/24 subnet).
  • I installed the standard openswan package.
  • each has a dummy interface which is accessible from the other end of the VPN tunnel.

This is how I configured the tunnel:

/etc/ipsec.conf (identical on both left and right):

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=192.168.0.12
    rightsubnet=10.2.0.0/16
    rightsourceip=10.2.0.1
    auto=start

/etc/ipsec.secrets (identical on both left and right):

192.168.0.11 192.168.0.12: PSK "mytestpassword"

/etc/rc.local (on left):

modprobe dummy
ifconfig dummy0 10.1.0.1 netmask 255.255.0.0

iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.0/16 ! -d 10.2.0.0/16 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart

exit 0

/etc/rc.local (on right):

modprobe dummy
ifconfig dummy0 10.2.0.1 netmask 255.255.0.0

iptables -t nat -A POSTROUTING -o eth0 -s 10.2.0.0/16 ! -d 10.1.0.0/16 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart

exit 0

Now, I would like to set up the following scenario:

desired net-to-net configuration

Issues I need to understand:

  • Can IPSec connect through a VPN gateway which is sharing a public ip via NAT (inbound NAT traversal)? Do NAT-T and IPSec passthrough relate to this or are they just for outbound NAT (i.e. dealing with clients which are behind NAT but where the gateway has a public IP)? Would it be sufficient to forward some ports from router1 to test, or would that be incompatible with IPSec?
  • Can both ends of an IPSec tunnel have dynamic IP's as long as one has a domain name and dynamic dns?
1
  • Question 1: yes, but there are limitations. If two machines will try to connect from the same IP address, firewall might not know were to forward IPSEC packets (non-tcp and non-udp). This doesnt has anything with this setup, but basically IPSEC packets do not have connection tracking on NAT, so it knows only ip number, which might work and sometimes might not Question 2: It can be configured this way since it's using DNS which is a separate layer, so I dont see the reason why not. Jul 12, 2012 at 20:57

2 Answers 2

3

Can IPSec connect through a VPN gateway which is sharing a public ip via NAT (inbound NAT traversal)? Do NAT-T and IPSec passthrough relate to this or are they just for outbound NAT (i.e. dealing with clients which are behind NAT but where the gateway has a public IP)? Would it be sufficient to forward some ports from router1 to test, or would that be incompatible with IPSec?

NAT-T as defined in RFC 3947 / 3948 is a UDP encapsulation of IPSec traffic. Without this encapsulation, IPSec uses own protocol types underneath of IP for both - the transport and the tunnel modes, making it impossible to work through NAT. With the UDP encapsulation, it would work over any NAT device capable of handling UDP.

The direction of the connection establishment does matter indeed as NAT routers are stateful and maintain UDP "connection" information only allowing for UDP "connections" initiated from within the NATed network. Creating a port forwarding rule for the UDP port used by IKE and the UDP encapsulation for ESP (4500/udp) would overcome this limitation, but obviously only allow for a single IPSec host configured in this way behind the NAT device.

Can both ends of an IPSec tunnel have dynamic IP's as long as one has a domain name and dynamic dns?

Yes, you do not need a static IP address, although it is likely to make your life easier as it removes two single points of failure (the DDNS provider / update process) from your configuration. Note that running with dynamic IP addresses on both ends with PSK authentication would require aggressive mode for IKE phase 1.

3
  • Why is aggressive mode necessary? Jul 13, 2012 at 1:27
  • @IsaacSutherland As you have no static IP addresses and the PSK does not carry identity info, you have to rely on the identity string transmitted by the remote party. In main mode, the identity is transmitted after the secure channel has been established, so it can't be used to select the key for the authentication / secure channel establishment phase. In aggressive mode this is different, also making the transmitted PSK hash open to offline bruteforce attacks. Certificates have the identity "built in" so this information is available when establishing the secure channel even in main mode.
    – the-wabbit
    Jul 13, 2012 at 9:59
  • I've started a new question specifically regarding using Aggressive Mode IKE with PSK: serverfault.com/questions/407667/… Any ideas on that one? Jul 13, 2012 at 21:37
1

I'm generally not the kind of guy to answer a well-thought out question with "go use something else", but... IPSec VPNs are always a problem to set up. Adding in NAT and dynamic IP's is just an invitation for frustration.

Have you taken a look at OpenVPN at all? It's a SSL-based VPN that tunnels everything through UDP port 1194 so you're not having to deal with ESP. You could probably get your WAN up-and-running in less than hour.

1
  • Sounds nice, but I've got a wireless gateway here that only supports IPSec. The plan was to swap out test2 with the gateway once I've got the tunnel working. So I'm kind of stuck with IPSec until I get fed up and buy a different gateway. Jul 13, 2012 at 1:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .