[luv-main] IPSec over IPv6 - packet routing
I've raised this on the StrongSwan list over the last several weeks, but with no reply so far - hence I'm raising the question here as well to gain a broader audience. I have been experimenting with Strongswan as an implmentation of IKEv2 (my ultimate interest is also in its implementation of mobile IPv6, but that's not of immediate concern). If I set up an IPSec tunnel with StrongSwan 4.5.2 between my laptop and an external host (or a virtual machine and another host with a single network interface such as eth0) all appears to work; but my desktop machine has both eth0 and ppp0 interfaces. The tunnel appears to be established correctly on both sides and the IPSec policy appears to be correct, but my machine can't send packets over the tunnel. The kernel log contains messages regarding pmtu discovery, and packet monitoring shows that neighbour discovery packets are being sent out the eth0 interface rather than ppp0, i.e., if I try to ping the remote host over the tunnel, I get a lot of neighbour discovery packets on eth0, whereas the traffic needs to be routed through the ESP encapsulation to ppp0 and onward to the destination. Obviously I can provide much more detail; the main problem at this stage is how to bring the problem to the attention of someone who is familiar with Linux IPSec sufficiently to identify the cause. I may yet get a response on the strongSwan list, of course.
Hi Jason Kernel mode ESP does not create an interface so I would not expect any neighbourhood discovery associated with IPsec. Maybe the IPv6 stack is trying to find a router which knows a path to the peer. I use strongswan quite a bit but have no experience using it over IPv6. Do you have a working implementation over IPv4? I would suggest using forceencaps=yes (NAT-T mode). This will force all the traffic (IKE and ESP) into UDP 4500 (at least it does in IPv4). I find this makes a lot of problems easier to diagnose and solve. Not sure if this is on-topic for luv-main. Should we continue the discussion on- or off-list? On Thu, Sep 15, 2011 at 2:50 PM, Jason White <jason@jasonjgw.net> wrote:
I've raised this on the StrongSwan list over the last several weeks, but with no reply so far - hence I'm raising the question here as well to gain a broader audience.
I have been experimenting with Strongswan as an implmentation of IKEv2 (my ultimate interest is also in its implementation of mobile IPv6, but that's not of immediate concern).
If I set up an IPSec tunnel with StrongSwan 4.5.2 between my laptop and an external host (or a virtual machine and another host with a single network interface such as eth0) all appears to work; but my desktop machine has both eth0 and ppp0 interfaces.
The tunnel appears to be established correctly on both sides and the IPSec policy appears to be correct, but my machine can't send packets over the tunnel. The kernel log contains messages regarding pmtu discovery, and packet monitoring shows that neighbour discovery packets are being sent out the eth0 interface rather than ppp0, i.e., if I try to ping the remote host over the tunnel, I get a lot of neighbour discovery packets on eth0, whereas the traffic needs to be routed through the ESP encapsulation to ppp0 and onward to the destination.
Obviously I can provide much more detail; the main problem at this stage is how to bring the problem to the attention of someone who is familiar with Linux IPSec sufficiently to identify the cause.
I may yet get a response on the strongSwan list, of course.
_______________________________________________ luv-main mailing list luv-main@lists.luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Richard Andrews <bflatmaj7th@gmail.com> wrote:
Kernel mode ESP does not create an interface so I would not expect any neighbourhood discovery associated with IPsec. Maybe the IPv6 stack is trying to find a router which knows a path to the peer.
I think so. It's fine without an IPSec tunnel, but, for whatever reason, not when a tunnel is in place.
I use strongswan quite a bit but have no experience using it over IPv6. Do you have a working implementation over IPv4?
No, although I could try it now that I have a static IPv4 address.
I would suggest using forceencaps=yes (NAT-T mode). This will force all the traffic (IKE and ESP) into UDP 4500 (at least it does in IPv4). I find this makes a lot of problems easier to diagnose and solve.
thanks.
Not sure if this is on-topic for luv-main. Should we continue the discussion on- or off-list?
I'm sure it's on topic here, as it's Linux-related.
On Sat, Sep 17, 2011 at 9:47 AM, Jason White <jason@jasonjgw.net> wrote:
Richard Andrews <bflatmaj7th@gmail.com> wrote:
Kernel mode ESP does not create an interface so I would not expect any neighbourhood discovery associated with IPsec. Maybe the IPv6 stack is trying to find a router which knows a path to the peer.
I think so. It's fine without an IPSec tunnel, but, for whatever reason, not when a tunnel is in place.
Yet you say the tunnel appears to work. "ipsec statusall" should show a child SA with an ID number in {} braces on both peers. One reason I prefer NAT-T mode is that the same UDP socket is used for IKE and ESP; it's very difficult to have keying work but not transport. That issue has been a frequent frustration with traditional IPsec for me.
participants (2)
-
Jason White -
Richard Andrews