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.

Reply via email to