OpenWrt Forum Archive

Topic: IPSec Site-to-Site tunnel not forwarding traffic

The content of this topic has been archived on 22 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello all,

I am having a problem getting a site-to-site connection working using PSK and I was hoping you’d be able to offer some help.  I am using strongSwan 5.2 (U5.2.0/K3.14.16) on openWRT Chaos Calmer (Linux OpenWrt 3.14.16 #7 SMP Tue Jan 26 18:17:28 EST 2016 armv7l GNU/Linux) running on a gateworks 5300 (http://www.gateworks.com/product/item/v … -processor) which has a Freescale i.MX6 SoC.  I have two of the GW5300s each with this configuration.

I have them both set up using the example here: https://www.strongswan.org/uml/testresu … t2net-psk/. All of the ipsec configuration files have been copy and pasted from the example into the corresponding configuration file on each of the 5300s.

https://www.strongswan.org/testing/testresults/images/a-m-w-s-b.png

here is how i have the interfaces configured:

/etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd58:1732:4ca3::/48'

config interface 'LAN0'
        option proto 'static'
        option ifname 'eth0'
        option ipaddr '192.168.0.1'
        option netmask '255.255.0.0'

config interface 'LAN1'
        option proto 'static'
        option ifname 'eth1'
        option ipaddr '10.1.0.1'
        option netmask '255.0.0.0'

I am able to successfully start the tunnel and the connection completes successfully. Here are the details of the tunnel as printed by 'ipsec statusall'

root@OpenWrt:/# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.0, Linux 3.14.16, armv7l):
  uptime: 8 minutes, since Jan 29 20:54:24 2016
  malloc: sbrk 102400, mmap 0, used 87952, free 14448
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown
Listening IP addresses:
  192.168.0.1
  10.1.0.1
Connections:
     net-net:  192.168.0.1...192.168.0.2  IKEv2
     net-net:   local:  [moon.strongswan.org] uses pre-shared key authentication
     net-net:   remote: [sun.strongswan.org] uses pre-shared key authentication
     net-net:   child:  10.1.0.0/16 === 10.2.0.0/16 TUNNEL
Security Associations (1 up, 0 connecting):
     net-net[1]: ESTABLISHED 6 minutes ago, 192.168.0.1[moon.strongswan.org]...192.168.0.2[sun.strongswan.org]
     net-net[1]: IKEv2 SPIs: 1344c48f06c482a6_i* 6b32dfe2942b78f9_r, pre-shared key reauthentication in 47 minutes
     net-net[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
     net-net{1}:  INSTALLED, TUNNEL, ESP SPIs: ccbb4a8b_i c4dc3108_o
     net-net{1}:  AES_CBC_128/HMAC_SHA1_96, 168 bytes_i (2 pkts, 368s ago), 420 bytes_o (5 pkts, 368s ago), rekeying in 8 minutes
     net-net{1}:   10.1.0.0/16 === 10.2.0.0/16

Using the names from the example I posted above:

Alice (10.1.0.10) can ping Moon (10.1.0.1) & Sun (10.2.0.1) but not Bob (10.2.0.10)
Bob (10.2.0.10) can ping Sun (10.2.0.1) & Moon (10.1.0.1) but not Alice (10.1.0.10)

Since Alice (10.1.0.10) can ping Sun (10.2.0.1) but not Bob (10.2.0.10) I am assuming what is happening is that the eth1 interface on Sun (10.2.0.1) is not forwarding the packets from Alice (10.1.0.10) on to Bob  (10.2.0.10).  After googling the issue some I added the following lines to /etc/firewall.user

iptables -t nat -I POSTROUTING -s 10.1.0.0/16 -o eth0 -m policy --dir out --pol ipsec --proto esp -j ACCEPT
iptables -t nat -I PREROUTING -s 10.2.0.0/16 -i eth0 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -A input_rule -p esp -j ACCEPT
iptables -A input_rule -p udp --dport 500 -j ACCEPT
iptables -A input_rule -p udp --dport 4500 -j ACCEPT

but this does not fix the problem. hmm so Alice can still not ping Bob... Here is the output of 'iptables -L'

root@OpenWrt:/# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  10.2.0.0/16          10.1.0.0/16          policy match dir in pol ipsec reqid 1 proto esp
ACCEPT     all  --  10.1.0.0/16          10.2.0.0/16          policy match dir out pol ipsec reqid 1 proto esp

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

which shows that the rules took....

when i type 'ip route list table 220'

root@OpenWrt:/# ip route list table 220
10.2.0.0/16 via 192.168.0.2 dev eth0  proto static  src 10.1.0.1

it shows that 10.2.x.x will get routed to 10.1.0.1.... so I am really at a loss now as to why Alice and Bob can't ping each other and I am hoping someone here may know and can help.

It is not clear what you are insinuating John, my post is not a commentary but very much a question to a problem I have yet to solve... For some reason my traffic is not getting forwarded on to the computers on the other side of the tunnel. I laid out my current setup in hopes that someone with a better understanding of IPSec and Networking than myself may see what I have misconfigured or any steps I have missed. I have tried solving this on my own and continue to do so but I have yet to find anything online that fixes the problem. Any help would be greatly appreciated

Not that this will be terribly useful for anyone that has this problem and finds this post, but I did manage to get this working. I wish I could detail how I did it but I do not know. All that is different between my current setup and the setup I detailed in the OP is that I am using a different openWRT image that I built from source and customized via menuconfig. I removed a lot of extra packages including luCI and I replaced dropbear with openssh. One difference I noticed is on my original setup (the one that did not work) under ifconfig I did not have an ipsec0 interface. Whereas on my working setup I have an ipsec0 interface even before I establish the connection.

It is probably worth noting that the image I was working with that was not working, I had also built from source and had added strongswan in manually.

I have same problem... Can you help me and publish your /etc/config/network and firewall files?

UPD:
192.168.0.0/22 is remote network.
I have add this to firewall.user:
iptables -t nat -A postrouting_rule -d 192.168.0.0/22 -j ACCEPT

but all works fine only after reboot!

(Last edited by NoNeed on 20 Jun 2016, 17:08)

jyeagley wrote:

It is probably worth noting that the image I was working with that was not working, I had also built from source and had added strongswan in manually.

I've configured IPSec on the stock OpenWrt image using the strongswan package from the Chaos Calmer repo and it works.

NoNeed wrote:

I have same problem... Can you help me and publish your /etc/config/network and firewall files?

Can you post /etc/ipsec.conf for both of the gateways?

The only rules you should need to add on either gateway are to allow ESP, udp 500, and udp 4500 ports on the WAN interface. For a routed subnet, the ipsec daemon will handle adding the appropriate rules to route traffic.

config rule
    option src 'wan'
    option proto 'esp'
    option target 'ACCEPT'
    option name 'ESP'

config rule
    option src 'wan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'
    option name 'isakmp'

config rule
    option src 'wan'
    option proto 'udp'
    option dest_port '4500'
    option target 'ACCEPT'
    option name 'IKEv2'

The discussion might have continued from here.