[strongSwan] Customizing routing
bldrdash at gmail.com
Sat Dec 19 18:31:10 CET 2015
On Sat, Dec 19, 2015 at 5:53 AM, Jan Palus <jan.palus at gmail.com> wrote:
> After further experiments (without TRACE yet though) the issue seems to
> always occur when rightsubnet=0.0.0.0/0. With same configuration in place:
> leftupdown script populating routing table and iptables chains:
> iptables -t nat -I POSTROUTING -d A,B -j SNAT --to-source
> iptables -t nat -I POSTROUTING -o wan -m policy --dir out --pol ipsec -j
> ip route add A dev wan proto static scope global src $PLUTO_MY_SOURCEIP
> table 220
> ip route add B dev wan proto static scope global src $PLUTO_MY_SOURCEIP
> table 220
> switching between rightsubnet=0.0.0.0/0 and rightsubnet=A either results
> hanging connections (occasionally) or works fine. Connection is always
> tested between C and A.
> Users mailing list
> Users at lists.strongswan.org
I'm working on almost the same setup as you in OpenWRT 15 and thought I'd
post some quick notes I've observed, that may or may not help. I'm working
on my config this weekend and can post the final results once I'm done,
although in my case, the wireless clients send all traffic through OpenWRT
via ipsec to a remote gateway.
Anyway, with OpenWRT 15, there is a couple of issues I've noticed with the
strongswan packages. The one that works for me is "strongswan-default",
although "strongswan-full" may work. "strongswan" alone gives me some
racoon errors and doesn't install various ipsec related packages.
In addition, there is a dependancy issue with 15 and the ip-full package...
it doesn't actually get installed. You can test this by typing "ip xfrm
policy". If it gives an error, you actually have the "ip" package and not
"ip-full". To fix, type
# opkg remove --force-depends ip
# opkg install --force-overwrite ip-full
Lastly, I had issues with http connections "hanging", which turned out to
be MTU related. For example www.speedtest.net wouldn't even load. I had
some mangle rules to fix this, but had them in the wrong table. (Mine
needed to be in mangle/FORWARD table). Anyway, to confirm MTU is not an
issue, on the remote GW, you may want to try:
# tcpdump -qnn -e icmp[icmptype] == 3 && icmp[icmpcode] == 4
and see if you're getting any fragment messages. If so, your mangle rule
may be in the wrong place for your setup.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users