[Swan] libreswan tunnel causing ICMP redirects to go wrong way

Eric Paris eparis at redhat.com
Thu Jan 15 01:33:22 EET 2015


I'm trying to get something set up which I imagine 100+s of people have
done before me. This really shouldn't be so hard. I am trying to get a
LAN behind a Linux box which is acting as a router connected to the
internet. I am trying to start by getting ALL traffic from the LAN to be
forwarded to a server someone on the other side of the internet. The
traffic should then go to its final destination (back out on the
internet) but the source should appear to be from the server. The
typical reason people want to do this is to watch TV, but for this
person, that's not the motivating factor. I would like to be able to
intelligently decide on the single router box which traffic I forward
over the tunnel and have SNAT'd as the server on the other side, and
which traffic I dump directly on the internet. But I see that as step 2.

So I have it mostly working. But only mostly. The problem is with MTUs
and dropped/missing/misrouted packets. From my router I can run:

ping 8.8.8.8 -c 2 -M do -s 1450

and it complains that the packet is too large and the mtu=1422. From a
client on the LAN I run the same command and get no response. If I use
-s 1394 (so the total IP packet is 1422) ping work perfectly on both the
clients and the routers.

I tried setting the mtu on the internal nic of the router to 1422. I
figured that would force everyone on the LAN to back off. But I can
still ping the router from the lan with packets bigger that 1422! I
don't know what the deal is with that, wholely unrelated to this problem
I expect...

I know that the mss-to-pmtu type suggestions in iptables rules won't
help, because this is ICMP, not TCP. This is only about pmtu being
busted. I think because ICMP packets are going the wrong way. If I
capture packets on the server, on the other side of the internet, I see
the ICMP unreachable with mss=1422 packets with
  source: router external interface
  destination: my client on the lan who isn't getting his packets
So the router is creating the ICMP unreachable messages, but instead of
sending them out the LAN interface to the client who can do something
about it, the router is encrypting them and sending them to the server
on the other side of the internet, where they just get lost going
nowhere...

So why are ICMP packets created on the router not going out the LAN
interface and instead going out the tunnel to the server?  How do I fix
it? What do I have set up wrong?

My SERVER config:
# iptables -nvL
Chain INPUT (policy ACCEPT 1623K packets, 497M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 2678K packets, 1660M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1864K packets, 1674M bytes)
 pkts bytes target     prot opt in     out     source               destination         


# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 15807 packets, 1389K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 664 packets, 44404 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 218 packets, 16398 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 218 packets, 16398 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   212 RETURN     all  --  *      *       0.0.0.0/0            172.16.0.0/24       
 131K   11M MASQUERADE  all  --  *      *       192.168.0.0/16       0.0.0.0/0           


# cat /etc/ipsec.d/eparis-vpn.conf 
conn tv
    authby=secret
    pfs=no
    auto=add
    rekey=no
    left=104.236.78.47
    leftsubnet=0.0.0.0/0
    right=%any
    rightsubnet=vhost:%priv,%no
    ike-frag=yes

My ROUTER config:
# iptables -nvL
Chain INPUT (policy ACCEPT 186K packets, 153M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 252K packets, 161M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 174K packets, 28M bytes)
 pkts bytes target     prot opt in     out     source               destination         


# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 4303 packets, 607K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 1920 packets, 175K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 25397 packets, 1897K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 25374 packets, 1889K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   252 RETURN      all  --  *      *      0.0.0.0/0            172.16.0.0/24
 2403  439K MASQUERADE  all  --  *      *       172.16.0.0/24        0.0.0.0/0           


# cat /etc/ipsec.d/eparis-vpn.conf 
conn tv
    authby=secret
    pfs=no
    auto=up
    rekey=no
    left=104.236.78.47
    leftsubnet=0.0.0.0/0
    right=%defaultroute
    ike-frag=yes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: john-network.png
Type: image/png
Size: 31087 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20150114/8ce3829c/attachment-0001.png>


More information about the Swan mailing list