On 9/12/2017 9:32 AM, Paul Wouters wrote: > On Thu, 7 Sep 2017, Jim Garrison wrote: > >> 192.168.10.0/24 >> | >> +---+ .7 | >> | A |------+ _____ >> +---+ | ( ) >> | .254 +---+ Ext IP ( ) >> +----Ri| R |Re-------( cloud ) >> | +---+ ( )\ iPhone >> | \ (_____) \ +---+ >> \ ------| | >> \ | B | >> \ 192.168.11.80 | | >> +------VPN-Tunnel---------| | >> IKEv1 XAUTH with PSK +---+ > > So is the addresspool range you handing out a chunk of the LAN? > If this is a dedicated subnet, and you are sure your > routers know how to route to it, then it should work. > > If you pick IPs as a chunk of the local LAN to use as addresspool, > you need to use a recent libreswan to ensure you have proper proxyarp > working. It might also require enabling a /proc value. >
Based on your comments I did a thorough re-analysis of packet flow. I did find one firewall rule that needed changing, and that got the packet flow closer to working, but it's still not quite there. First I tried to find the virtual interface [jhg@janus sysconfig]$ sudo ipsec tncfg /usr/libexec/ipsec/tncfg: NETKEY does not support virtual interfaces. * Crucial Epiphany * I finally figured out that the ipsec tunnel does not create a virtual adapter, it makes the tunneled traffic look like it is coming in through the external interface. So my firewall rule for forwarding, that blocks everything except RELATED, ESTABLISHED, needs to have a hole punched in it for 192.168.11.64/26 to allow the VPN address pool to "live" behind the external interface. iptables -A FORWARD_FILTER -i eth1 -s 192.168.11.64/26 -j ACCEPT This allows the packets to get from the router onto the LAN and to host A, confirmed by watching tcpdump on both router adapters. However, though host A was now receiving the packets it was not responding to them. Given the epiphany however, it was a short step to realize that Windows Firewall was ALSO in the way, as it did not recognize the VPN subnet. Adding a custom rule mirroring the one in iptables allowed everything to finally work. Thanks for your comments that got me to attack the problem with renewed organization. Side comment: Having to punch a hole in the firewall for a subnet seems like a slight risk... is it? -- Jim Garrison ([email protected]) PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
