"problematic"? By dropping those ICMP messages, you effectively cripple the connectivity of those clients if problems occur.
On 11.04.2018 19:35, Thor Simon wrote: > 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:[email protected]] On Behalf Of Noel > Kuntze > Sent: Wednesday, April 11, 2018 1:23 PM > To: Michael .. <[email protected]>; [email protected] > 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.
