1

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.
  • 3
    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 if.usp.br/pub/documentos/seguranca/roteadores_linux_v1.pdf – Rui F Ribeiro Jul 19 '18 at 17:47
  • 1
    @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 [<o>]!) – Eduardo Lucio Jul 20 '18 at 2:51
  • 1
    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 6: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 6:59
  • This question is closely related to this thread unix.stackexchange.com/questions/458502/… . – Eduardo Lucio Aug 3 '18 at 20:44
4

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.

  • 1
    "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 unix.stackexchange.com/q/457572/61742 – Eduardo Lucio Jul 20 '18 at 23:51
3

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
  • 1
    @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
  • 2
    @EduardoLucio - I have a collection of Vagrantfiles here - 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
  • 1
    @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

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.