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.
In other words, everybody can ping everybody else EXCEPT B cannot ping
anybody inside the 192.168.10.0/24 network, while still being able to
ping R's internal network address.
So what does tcpdump say in the various locations about the packet flow?
What does "ipsec verify" say on the libreswan server?
janus.localdomain Thu Sep 7 20:01:38 PDT 2017
XFRM state:
src xxx.xxx.45.71 dst xxx.xxx.94.61
proto esp spi 0xde18dd2e reqid 16397 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x23faf136fcde2c1b8c31f4cc9fea0003fa2985d2
enc cbc(aes)
0x04c42120ad0357f2406c5a9fdfe3f5ad8fcc45c3ed3aa69aeb1f010f996e3a10
encap type espinudp sport 42703 dport 4500 addr 0.0.0.0
src xxx.xxx.94.61 dst xxx.xxx.45.71
proto esp spi 0x0aa354d9 reqid 16397 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x3ecfa164b8455dfca08b985c8e1b326adba2fa2a
enc cbc(aes)
0xb81e5bfa39b63e493fcce3b2104ee5f2dd2f81fe8a45ec7665dd182493e525f9
encap type espinudp sport 4500 dport 42703 addr 0.0.0.0
XFRM policy:
src 0.0.0.0/0 dst 192.168.11.80/32
You might also need a passthrough connection to exclude LAN traffic from
being IPsec'ed?
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
