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.

Daniel
  • 101
  • 3

1 Answers1

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.

RalfFriedl
  • 3,108
  • 4
  • 13
  • 17
  • 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 09 '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 09 '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 09 '18 at 19:09
  • Run `tcpdump -i any port radius`. What is the source and destination of the packets? – RalfFriedl Nov 10 '18 at 09: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
  • Can you run `tcpdump` on the RADIUS server? Did you try the `iptables` rule without the `-s` option? The rule should apply anyway. Are there other `iptables` rules, network rules shown by `ip -4 route show table all`? – RalfFriedl Nov 10 '18 at 17:28
  • I can run Wireshark on the RADIUS server. No packages are being received at the RADIUS server - but ICMP Echo Requests are received! The `iptables` rule without `-s` does not resolve the problem. There are other rules: https://pastebin.com/rDF9G05F – Daniel Nov 10 '18 at 18:37
  • Is there some other firewall between you an the RADIUS server? Can you look at the packets on the other VPN gateway? – RalfFriedl Nov 10 '18 at 18:39
  • No there is no firewall between me and the RADIUS server. I can look at the packets being received by 10.42.0.16/28, but AWS does not allow me to see the log at the VPN gateway. – Daniel Nov 10 '18 at 19:06