Use the LANs of one server to access the LAN of another

Question

I'm a bit lost here, so I'm asking for your help. =D

I have three servers:

1# - LANs A and B
2# - LANs B and C
3# - LANs C and D

How can I make server 1# access through LAN B an ip that is in LAN D of the 3# server using the 2# server?

NOTE: We can use the firewall-cmd (iptables) or any other feature that is available on a CentOS 7.

To illustrate

LAN B - 192.168.56.0/24
LAN C - 10.8.0.0/24
LAN D - 10.0.4.0/24

That is, a ping (ping 10.0.4.4) runs on the server 1# 'traversing' path B -> C -> D.

NOTE: I've done many and many tests and I really do not know how to solve this... =[

EDIT #1

To make things easier, I decided to enrich this thread with real information.

Server #1

LAN A -> Ignored

LAN B -> enp0s17 (192.168.56.0/24)

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:12:26:e2:6c brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.122/24 brd 192.168.56.255 scope global noprefixroute enp0s17
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:12ff:fe26:e26c/64 scope link 
       valid_lft forever preferred_lft forever

Server #2

LAN B -> enp0s17 (192.168.56.0/24)

LAN C -> tun0 (10.8.0.0/24)

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:2c:d1:58 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.10/24 brd 10.0.2.255 scope global noprefixroute dynamic enp0s8
       valid_lft 888sec preferred_lft 888sec
    inet6 fe80::2c5c:27aa:2636:8dc9/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:1c:a6:b9:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.120/24 brd 192.168.56.255 scope global noprefixroute enp0s17
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:1cff:fea6:b959/64 scope link 
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::6a67:7379:b64:967c/64 scope link flags 800 
       valid_lft forever preferred_lft forever

Server #3

LAN C -> tun0 (10.8.0.0/24)

LAN D -> enp0s8 (10.0.4.0/24)

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:71:77:07 brd ff:ff:ff:ff:ff:ff
    inet 10.0.4.4/24 brd 10.0.4.255 scope global noprefixroute dynamic enp0s8
       valid_lft 1115sec preferred_lft 1115sec
    inet6 fe80::899f:8ca4:a7c6:25a7/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp0s17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:ea:4e:40:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.121/24 brd 192.168.56.255 scope global noprefixroute enp0s17
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:eaff:fe4e:40ae/64 scope link 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.6/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::48c2:b3cd:5845:5d35/64 scope link flags 800 
       valid_lft forever preferred_lft forever

Based on the @slm suggestions we did the following:

Commands on Server #2

$ echo -n "net.ipv4.ip_forward=1" >> /etc/sysctl.d/ip_forward.conf
$ sysctl -w net.ipv4.ip_forward=1

$ firewall-cmd --permanent --direct --passthrough ipv4 -t nat \
   -I POSTROUTING -o tun0 -j MASQUERADE -s 192.168.56.0/24
$ firewall-cmd --reload

Commands on Server #1

$ ping 10.0.4.4

PROBLEM -> There is no response for the ping 10.0.4.4 command.
IMPORTANT -> These are tests I'm doing on virtual machines.

You need to enable ip forwading and create static routes. I recommend reading CCNA introductory materials to get a foundation of network and routing core concepts. (off-topic) veja isto http://www.if.usp.br/pub/documentos/seguranca/roteadores_linux_v1.pdf — Rui F Ribeiro, Jul 19 '18 at 17:47
@RuiFRibeiro An excellent reference material about routing and other concepts for GNU/Linux. Very enlightening. I read all of it. Highly recommended. Thank you! (Obrigado amigo []!) — Eduardo Lucio, Jul 20 '18 at 02:51
A bit outdated in certain parts, but a good document, and I know you guys on the other side of the pond actually prefer more than us things in pt. — Rui F Ribeiro, Jul 20 '18 at 06:04
Just define static route to LAN D. Server 1# can access LAN D.Server was using static IP address. — supriady, Jul 20 '18 at 06:59
This question is closely related to this thread https://unix.stackexchange.com/questions/458502/how-can-i-use-isc-kea-dhcp-dhcpv4-server-to-push-routes-to-clients/460415#460415 . — Eduardo Lucio, Aug 03 '18 at 20:44

score 4 · Accepted Answer · answered Jul 20 '18 at 06:32

That's a very basic networking thing: If you want to connect different LAN segments, you need a router. You don't need NAT, you don't need iptables, you just route, plain and simple.

For some reason people seem to think routing needs at least NAT or iptables, and the internet is full of advice to that end. It's really not necessary, and a pet peeve of mine.

All you need to do is

1) Enable forwarding on server #2. That has already been described (add a file in /etc/sysctl.d/, reboot and see if cat /proc/sys/net/ipv4/ip_forward shows 1, or enable it directly with echo 1 > /proc/sys/net/ipv4/ip_forward).

2) Set a route on all hosts which want to use the gateway. That's what most people forget. So on server #1, you need something like

ip route add 10.8.0.0/24 dev enp0s17 via 192.168.56.120
ip route add 10.0.4.0/24 dev enp0s17 via 192.168.56.120

and the same on all other hosts on LAN A and B which want to reach LAN C and D. On server #3 (and all other hosts it concerns), you need

ip route add 192.168.56.0/24 dev tun0 via 10.8.0.1

That tells each host that when it wants to reach the remote LAN, it should go via server #2, with the appropriate IP address of server #2 in the local LAN.

You can test that routing works with ip route get a.b.c.d on server #1 and server #3. Now test with ping. If something is still wrong, debug with tcpdump. If a firewall is in the way, disable it as necessary.

When all works, use some way to make the routes permanent, for example distribute them via DHCP, or add them to a suitable configuration file.

"When all works, use some way to make the routes permanent, for example distribute them via DHCP, or add them to a suitable configuration file." -> In this thread I try to follow your suggestion. Thanks! =D https://unix.stackexchange.com/q/457572/61742 — Eduardo Lucio, Jul 20 '18 at 23:51

score 3 · Answer 2 · answered Jul 19 '18 at 18:39

From the looks of it you're describing a NAT. A NAT (Network Address Translation) is where traffic from one network (LAN) is masqueraded as coming from another server (WAN) which typically sits in between the 2 networks.

 server #1                                                                                             
 +-----------------+                                                                                   
 |                 |                                                                                   
 |                 |                                                                                   
 |         10.0.0.2|------+                                                                            
 |                 |      |            server #3 (NAT)              +--------------+                   
 +-----------------+    +-------+     +-----------------+           |              |                   
                        |switch |-----+10.0.0.1         |           |     (D)      |                   
                        +-------+     |                 |           |              |                   
 server #2                 |          | (C)   54.1.1.23 |-----------+ 54.1.1.1     |-----+Internet     
 +-----------------+       |          |                 |           |              |                   
 |                 |       |          +-----------------+           |              |                   
 |           (B)   |       |                                        |              |                   
 |         10.0.0.3|-------+                                        +--------------+                   
 |                 |                                                                                   
 +-----------------+

This tutorial discusses how you'd go about setting it up on CentOS 7.x, titled: Deploy Outbound NAT Gateway on CentOS 7.

The gist of this type of set up is to configure the server in the (C) position with 2 NICs having 2 IP addresses from two different networks. You also need to set this server up so that it'll forward traffic. Linux system's default behavior is to not do that:

$ sudo sysctl -w net.ipv4.ip_forward=1
$ sudo 'echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/ip_forward.conf'

After doing this you need to configure the firewall on system (C) so that it'll forward traffic as well:

$ sudo firewall-cmd --permanent --direct --passthrough ipv4 -t nat \
    -I POSTROUTING -o eth0 -j MASQUERADE -s 10.0.0.0/24
$ sudo firewall-cmd --reload

I tried what you suggested, but it did not work. I add more information in the thread (see "PLUS") to make things clearer. — Eduardo Lucio, Jul 19 '18 at 19:45
@EduardoLucio - if you're using VMs then you're introducing a whole host of new potential issues. You can run `tcpdump -i any icmp` on the VMs to see if the ping packets are even reaching the VM to start. You have to debug it this way, the above is known to work on physical boxes, but with virtualbox and other virtualization techs. they can influence this. — slm, Jul 19 '18 at 19:54
@EduardoLucio - I have a collection of Vagrantfiles here - https://github.com/slmingol/vagrantfiles. that I know work with the above, in so far as, that I can ping from VM to VM. — slm, Jul 19 '18 at 19:56
"If you're using VMs then you're introducing a whole host of new potential issues" -> I believe in you. But, I need to simulate before the real thing and now I do not know how to act to circumvent this scenario. Any suggestion? Thanks a lot! — Eduardo Lucio, Jul 19 '18 at 20:53
@EduardoLucio - use `tcpdump` to see if the ping traffic is getting to the VM. I showed the `tcpdump` cmd to run inside the VM. I also gave your a link to Vagrantfiles for CentOS & Ubuntu that I maintain that you can use to get your virtualbox in a known state so you can do your testing. — slm, Jul 19 '18 at 20:54
Thank you very much! Sorry for the my lack of attention with you. I've been caught up in this problem for a few days and I'm already entering the "desperation mode". =D — Eduardo Lucio, Jul 19 '18 at 21:01
@EduardoLucio - no worries, just extend me the same courtesy 8-). — slm, Jul 19 '18 at 21:02

Use the LANs of one server to access the LAN of another

To illustrate

EDIT #1

2 Answers2

Linked