0

The situation in my environment is as follows:

There is a network (213.213.213.128/26) with a VPN gateway (213.213.213.155).

There is a distant network (10.42.0.16/28) on AWS which is connected with 213.213.213.128/26 through AWS VPC VPN which has a RADIUS server on 10.42.0.30.

I wish external clients to connect with 213.213.213.128/26 using the VPN gateway 213.213.213.155 authenticating through 10.42.0.30.

My problem is, that 213.213.213.155 does not reach 10.42.0.30 as it sends through the wrong interface. When I add

iptables -t nat -A POSTROUTING -s <address of the tunnel interface> -d 10.42.0.16/28 -j SNAT --to-source 213.213.213.155

I am able to ping 10.42.0.30, but the RADIUS packages are not transmitted through the tunnel.

How do I have to change the network configuration to allow the gateway (213.213.213.155) to connect to hosts in 10.42.0.16/28?

I am using strongswan as VPN server. Pinging with -I 213.213.213.155 is successful without the iptables rule.

EDIT

The routing table is as follows:

10.0.0.0/8 dev Tunnel1 scope link metric 100
10.0.0.0/8 dev Tunnel2 scope link metric 200
213.213.213.128/26 dev eno1 proto kernel scope link src 213.213.213.155
169.254.21.173 dev Tunnel1 proto kernel scope link src 169.254.21.174
169.254.21.233 dev Tunnel2 proto kernel scope link src 169.254.21.234

Modifying the routing table to:

10.0.0.0/8 dev Tunnel1 scope link metric 100 src 213.213.213.155
10.0.0.0/8 dev Tunnel2 scope link metric 200 src 213.213.213.155
213.213.213.128/26 dev eno1 proto kernel scope link src 213.213.213.155
169.254.21.173 dev Tunnel1 proto kernel scope link src 169.254.21.174
169.254.21.233 dev Tunnel2 proto kernel scope link src 169.254.21.234

allows the ping to go through without -I but traceroute finds no route to host. tracepath gets no replies.

0

The preferred solution for such problems is to set up proper routing entries. Using iptables can work if you don't have access to the routing table entries on one of the systems.

So ideally you would have on 213.213.213.155 a route to 10.42.0.16/28 via 213.213.213.155 and on 10.42.0.30 a route to 213.213.213.128/26 via the local VPN gateway.

If you can't change the routing table on the RADIUS server and therefor need iptables, make sure the rule applies to the RADIUS packets that are sent. Use tcpdump to watch for RADIUS packets on interface any and note the source and destination addresses.

What is the purpose of limiting the iptables rule to -s <address of the tunnel interface>? Just removing that option may be enough to make it work.

As you can use iptables, you should be able to set up routing entries. Try

ip route add 10.42.0.16/28 src 213.213.213.155

This should be enough to assign the correct source address without using the -I option to ping, and it should use the source address for every other connection, including RADIUS. Normally the VPN software should be smart enough to set up something to that effect without additional configuration. If that doesn't work, you may need

ip route add 10.42.0.16/28 dev tun0 src 213.213.213.155

where tun0 is your VPN interface.

  • Thank you! The first ip route command returns RTNETLINK answers: No such device. The second works and allows the ping to go through without specifying -I. This does not resolve my problem though, RADIUS, LDAP, DNS all don't go through the VPN. traceroute can't find a route and tracepath gets constant no reply. Any clue? I added the routing tables to the original question. – Daniel Nov 9 '18 at 17:40
  • You added the same source address for both 10.0.0.0/8 routes. It probably should be the address of the respective tunnel interface. What is the origin of the RADIUS requests? The VPN gateway or something else? – RalfFriedl Nov 9 '18 at 17:51
  • These routes are created by a script supplied by AWS as there is a second tunnel as failsafe. The RADIUS requests are coming from the VPN gateway. – Daniel Nov 9 '18 at 19:09
  • Run tcpdump -i any port radius. What is the source and destination of the packets? – RalfFriedl Nov 10 '18 at 9:18
  • With and without src 213.213.213.155: 169.254.21.174."some port" > 10.42.0.30.radius. – Daniel Nov 10 '18 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.