0

the question is very similar to the one posted here: Routing via gateway to another subnet

My question is about the correct routing / iptable settings for the following network topology, which includes a site-to-site VPN between site-A and site-B.

Network Architecture

The client-A wants to access client-B, for instance a webserver is hosted on client-B. For simplicity I want to focus on site-A only. Let us assume that client-B has vpn-server-B as its gateway.

client-A can access the webserver on client-B, if client-A uses vpn-server-A as its gateway. But client-A also wants to access the internet via the gateway. Therefore, client-A sets gateway-A as its default gateway. So gateway-A should forward the traffic for 192.168.1.0/24 to vpn-server-A. I use firewall builder in order to configure the firewall and routing rules. I set up the following in firewall builder.

Firewall Builder

client-A can ping successfully client-B but no http(s) conection can be established. Having a look into the log file of gateway-A:

Apr  3 21:22:35 gateway-A kernel: [ 5456.799769] RULE 1 -- ACCEPT IN=eth0 OUT=eth0 MAC=00:11:22:33:44:55:00:55:44:33:22:11:08:00 SRC=192.168.0.100 DST=192.168.1.100 LEN=52 TOS=0x02 PREC=0x00 TTL=127 ID=28583 DF PROTO=TCP SPT=53133 DPT=443 WINDOW=8192 RES=0x00 CWR ECE SYN URGP=0
Apr  3 21:22:35 gateway-A kernel: [ 5456.814869] RULE 3 -- DENY IN=eth0 OUT=eth0 MAC=00:11:22:33:44:55:00:55:44:33:22:11:08:00 SRC=192.168.0.100 DST=192.168.1.100 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=28584 DF PROTO=TCP SPT=53133 DPT=443 WINDOW=260 RES=0x00 ACK URGP=0

The problem seems to be that the gateway-A does not redirect correctly the traffic to the vpn-server-A. As the last comment in the post linked above one should check the firewall. Probably an additional NAT is required but I do not understand why. The incoming request to access 192.168.1.0/24 at gateway-A should be just redirected to vpn-server-A.

pallago
  • 165
  • 6
  • Just route across the VPN. You should not need to NAT over the VPN as you have non-overlapping networks. NAT is not a substitute for routing. NAT is used for public<->private or overlapping networks, and it should be avoided whenever possible. Routing routes packets between networks, NAT translates network addresses in the packets, something not necessary for normal routing. – Ron Maupin Apr 03 '20 at 19:49
  • Thank you. However, I want to split the firewall (gateway-A) and the vpn-server-A. Is there another solution when I want to keep both servers, i.e,. gateway-A and vpn-server-A. Combining both is an option of course, which would solve the problem easily but I wanted to avoid it. – pallago Apr 03 '20 at 19:53
  • You can use simple routing. Packets are routed by the destination address on the packet. You can, for example, have a route for a server, a route for one network, other routes for different networks and/or hosts/servers, and a default route for the Public Internet. Unless you have overlapping network addressing, you would only need NAT for the private<->public Internet connection. – Ron Maupin Apr 03 '20 at 19:57
  • I have the routing table like this: 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.1.0 gateway-A 255.255.255.0 UG 0 0 0 eth0 so, the problem is as far as i understand not the routing but the rules according to the log file where the firewall rules are logged. – pallago Apr 03 '20 at 20:01
  • Assuming the VPN is working correctly, you need to add a static route on Gateway A in order to tell it that any packet directed to Site B should be sent to VPN-Server-A; you should also do the reverse on Gateway B (any packet directed to Site A should be sent to VPN-Server-B). – Massimo Apr 09 '20 at 22:48

1 Answers1

0

The firewall entries you are seeing are:

  • Initial TCP SYN (handshake step 1): Permited.
  • Server TCP SYN-ACK (handshake step 2): Missing?
  • Subsequent TCP ACK (handshake step 3): Blocked.

This suggests to me that the connection tracking on the firewall isn't working as you might expect. It suggests that either there is a routing problem (more info below), or a config problem with the firewall. I've no info on / experience with the firewall or VPN you're using, so more detail is hard to offer.

Routing problem:

In the diagram provided, it appears that traffic from client A to client B is routed over the interconnecting network directly (unencrypted) (because client A's gateway is gateway-A) and traffic from client B to client A is routed over the VPN (because client B's gateway is vpn-server-B).

Since the VPN server A is on the same network as client A, any packet routed over the VPN will be delivered directly to client A, and NOT through gateway-A.

This means that gateway-A will never see the TCP SYN-ACK from client B. Thus, as far as gateway-A is concerned, the connection between A and B is never set up, and further traffic from client A to client B on that connection is blocked.

Ping traffic is fine, because it goes out unencrypted, and comes back encrypted, but subsequent sent packets are identical to the first, so they are treated the same, as compared to a TCP connection which requires significant bidirectional communication even to get set up.

I suggest putting the VPN servers on separate networks from the clients (e.g. 192.168.100.0/24 and 192.168.101.0/24), and creating explicit routes in the gateway servers (gateway-A and gateway-B) that route traffic for the remote network through the VPN. That way you don't have to configure the clients specially.

Slartibartfast
  • 3,295
  • 18
  • 16