An alternative approach, which will also help if you have clients whose TCP connections are dropped when they have transient connectivity failures, is to use the packet filter to drop most (but not quite all) ICMP. In a similar configuration to yours, we've ended up passing echo/echorep and needs-frag; which means we drop redirects, ttl exceeded, and most unreachables, all of which, in practice, with our large population of mobile clients, ended up being problematic.
-----Original Message----- From: Users [mailto:users-boun...@lists.strongswan.org] On Behalf Of Noel Kuntze Sent: Wednesday, April 11, 2018 1:23 PM To: Michael .. <mi...@usa.com>; users@lists.strongswan.org Subject: Re: [strongSwan] Single physical interface "roadwarrior" responder using DHCP/FARP Hello Michael, Disable sending of redirects for traffic on that interface. The key is "net.ipv4.conf.INTERFACE.send_redirects". Kind regards Noel On 11.04.2018 18:56, Michael .. wrote: > Hi, > > I'm trying to configure a responder for use in a "roadwarrior" scenario, > albeit unsuccessfully. > > Topology/Config: > > -ip route > default via 192.168.1.254 dev eth0 src 192.168.1.1 metric 202 > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 metric 202 > > Default gateway @ 192.168.1.254 provides internet access and also inbound NAT > forwarding of ports 500/4500 from an internet IP. > > -ipsec.conf: > > > conn %default > ikelifetime=60m > keylife=20m > rekeymargin=3m > keyingtries=1 > keyexchange=ikev1 > conn rw > left=192.168.1.1 > leftsubnet=0.0.0.0/0 > leftauth=psk > right=%any > rightauth=psk > rightauth2=xauth > auto=add > rightsourceip=%dhcp > > -ip route show table 220 > 192.168.1.50 via 192.168.1.254 dev eth0 proto static > > Symptoms: > > I am able to establish a VPN connection from the internet to the responder > and the client is assigned an IP from the DHCP pool. > > The responder can ping the client's IP address assigned from DHCP - therefore > 2-way communication over the tunnel. The remote internet client can also > send packets over the tunnel to the rest of the 192.168.1.0/24 subnet which > reach their destination (e.g. to 192.168.1.2). The responder then correctly > replies to ARP on behalf of the clients address (e.g. 192.168.1.50) and the > return packet arrives to the responders interface. However, the responder is > replying with ICMP redirect to 192.168.1.254 to the sender and therefore the > return packet does not reach the client. > > Any ideas? > > Cheers, > > Michael.
