3

I have a site-to-site IPsec tunnel set up with strongSwan between my CentOS 7 virtual private server (public IP x.x.x.233 for subnet 172.25.10.0/24) and a customer's network (public IP y.y.y.24 for subnet 10.9.200.0/24). The tunnel seems to be connecting fine, but I can't get traffic to route over it. I'm trying to set up the 172.25.10.0/24 subnet on the same host that's acting as the gateway, which I assume I've done incorrectly.

The conn section of the ipsec.conf on the VPS is:

conn customer
    esp=aes256-sha1-modp1024
    ike=aes256-sha1-modp1024
    keyexchange=ikev1
    authby=psk
    left=%defaultroute
    leftsubnet=172.25.10.0/24
    leftfirewall=yes
    right=y.y.y.24
    rightsubnet=10.9.200.0/24
    auto=start

As far as I can tell, the tunnel itself is working fine. strongswan statusall on the VPS shows:

Security Associations (1 up, 0 connecting):
      customer[29]: ESTABLISHED 110 minutes ago, x.x.x.233[x.x.x.233]...y.y.y.24[y.y.y.24]
      customer[29]: IKEv1 SPIs: 0123456789abcdef_i* 0123456789abcdef_r, pre-shared key reauthentication in 50 minutes
      customer[29]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      customer{88}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: 01234567_i 01234567_o
      customer{88}:  AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 bytes_o, rekeying in 7 minutes
      customer{88}:   172.25.10.0/24 === 10.9.200.0/24

I set up a subnet IP (172.25.10.2) on the VPS on the same interface that holds the public IP (x.x.x.233) with:

ip addr add 172.25.10.2/32 dev eth0

But when I ping an IP on the remote network from the VPS, the ping is failing:

# ping -I 172.25.10.2 -c 3 10.9.200.254
PING 10.9.200.254 (10.9.200.254) from 172.25.10.2 : 56(84) bytes of data.

--- 10.9.200.254 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

A tcpdump shows me that the IPsec tunnel is not being used:

# tcpdump -n host 10.9.200.254 or host y.y.y.24
03:51:07.193494 IP x.x.x.233 > 10.9.200.254: ICMP echo request, id 10193, seq 1, length 64
03:51:08.193449 IP x.x.x.233 > 10.9.200.254: ICMP echo request, id 10193, seq 2, length 64
03:51:09.193452 IP x.x.x.233 > 10.9.200.254: ICMP echo request, id 10193, seq 3, length 64

I'm guessing that just adding the 172.25.10.2 IP to eth0 is not sufficient for it to figure out that my traffic should be routed over the tunnel, but I'm not sure what the right way to do it is.

For what it's worth, I also ran the following commands before turning on strongSwan:

# echo "net.ipv4.ip_forward=1" > /etc/sysctl.conf
# sysctl -p
# firewall-cmd --zone=public --permanent --add-service="ipsec"
# firewall-cmd --zone=public --permanent --add-port=4500/udp
# firewall-cmd --zone=public --permanent --add-masquerade
# firewall-cmd --reload

Otherwise I haven't touched the machine's configuration / routing rules / etc.

Ben
  • 33
  • 1
  • 3

2 Answers2

4

IPsec traffic should be routed, you probably hit the default NAT issue of the default NAT rule affecting IPsec traffic. The remedy is:

iptables -t nat -I POSTROUTING 1 -m policy --pol ipsec --dir out -j ACCEPT

Or an equivalent command with firewall-cmd --add-rule.

Vesper
  • 754
  • 1
  • 9
  • 29
4

If you have any NAT rules configured, like MASQUERADE via --add-masquerade, you have to exclude traffic that matches an IPsec policy from getting natted. Otherwise that traffic will just get natted to the public IP and won't match the IPsec policy anymore and will not go through the tunnel. As described on the strongSwan wiki you need to insert a rule like the following (before any NAT rules, which -I tries to do if NAT rules are already in place):

iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT

Could also be more specific if necessary (e.g. to only include certain source IPs). I don't know firewall-cmd so I'm not sure how you'd do that there. But something like the following (executed before the --add-masquerade line) might work:

firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 -m policy --pol ipsec --dir out -j ACCEPT
ecdsa
  • 3,800
  • 12
  • 26