On 20/07/18 15:08, Paul Wouters wrote: > Not too much to add but in the past I know that dummy interfaces could eat > packets. >
As a further follow up two things seemed to affect it. One was the use of a 'dummy0' address. As the machine was on a VM I gave it a 'Private' adaptor, which it then detected and added with a virt_io device. However, that still didn't seem to work. So I looked at the networking. I had decided to use DHCP to configure the external device. This gave the following Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.169.254 222.250.226.1 255.255.255.255 UGH 0 0 0 eth0 10.0.0.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 192.168.81.0 * 255.255.255.0 U 0 0 0 eth1 192.168.10.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 222.250.226.0 * 255.255.254.0 U 0 0 0 eth0 default 222.250.226.1 0.0.0.0 UG 0 0 0 eth0 inet addr:222.250.227.83 Bcast:222.250.227.255 Mask:255.255.254.0 (real IP obfuscated slightly) I have a feeling the 'Destination' may have caused the issue, though I am not 100% on this. I changed the IP to static and now have this, and it works.... Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 222.250.226.1 * 255.255.255.255 UH 0 0 0 eth0 10.0.0.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 192.168.81.0 * 255.255.255.0 U 0 0 0 eth1 192.168.10.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 222.250.226.0 * 255.255.254.0 U 0 0 0 eth0 default 222.250.226.1 0.0.0.0 UG 0 0 0 eth0 So a combination of driver/port and IP addressing seem to be at the heart of it. I am wondering if there is a setting in ipsec that may have got round this (the addresing, not the dummy0 issue)? nexthop perhaps?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
