[Swan] IKEv1 XAUTH VPN server -- so close and yet so far [RESOLVED]

[Jim Garrison]

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 at 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 (jhg at acm.org)
PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88