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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
1
down vote

favorite












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.






share|improve this question

















  • 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 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 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 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 at 6:59










  • This question is closely related to this thread unix.stackexchange.com/questions/458502/… .
    – Eduardo Lucio
    Aug 3 at 20:44
















up vote
1
down vote

favorite












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.






share|improve this question

















  • 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 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 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 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 at 6:59










  • This question is closely related to this thread unix.stackexchange.com/questions/458502/… .
    – Eduardo Lucio
    Aug 3 at 20:44












up vote
1
down vote

favorite









up vote
1
down vote

favorite











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.






share|improve this 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.








share|improve this question












share|improve this question




share|improve this question








edited Jul 19 at 19:51









slm♦

232k65479649




232k65479649









asked Jul 19 at 17:28









Eduardo Lucio

263111




263111







  • 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 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 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 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 at 6:59










  • This question is closely related to this thread unix.stackexchange.com/questions/458502/… .
    – Eduardo Lucio
    Aug 3 at 20:44












  • 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 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 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 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 at 6:59










  • This question is closely related to this thread unix.stackexchange.com/questions/458502/… .
    – Eduardo Lucio
    Aug 3 at 20:44







3




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 at 17:47





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 at 17:47





1




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 at 2:51




@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 at 2:51




1




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 at 6:04




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 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 at 6:59




Just define static route to LAN D. Server 1# can access LAN D.Server was using static IP address.
– supriady
Jul 20 at 6:59












This question is closely related to this thread unix.stackexchange.com/questions/458502/… .
– Eduardo Lucio
Aug 3 at 20:44




This question is closely related to this thread unix.stackexchange.com/questions/458502/… .
– Eduardo Lucio
Aug 3 at 20:44










2 Answers
2






active

oldest

votes

















up vote
3
down vote



accepted










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.






share|improve this answer

















  • 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 at 23:51


















up vote
3
down vote













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





share|improve this answer





















  • 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 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 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 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 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 at 20:54











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f457270%2fuse-the-lans-of-one-server-to-access-the-lan-of-another%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
3
down vote



accepted










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.






share|improve this answer

















  • 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 at 23:51















up vote
3
down vote



accepted










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.






share|improve this answer

















  • 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 at 23:51













up vote
3
down vote



accepted







up vote
3
down vote



accepted






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.






share|improve this answer













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.







share|improve this answer













share|improve this answer



share|improve this answer











answered Jul 20 at 6:32









dirkt

13.8k2930




13.8k2930







  • 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 at 23:51













  • 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 at 23:51








1




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 at 23:51





"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 at 23:51













up vote
3
down vote













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





share|improve this answer





















  • 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 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 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 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 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 at 20:54















up vote
3
down vote













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





share|improve this answer





















  • 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 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 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 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 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 at 20:54













up vote
3
down vote










up vote
3
down vote









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





share|improve this answer













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






share|improve this answer













share|improve this answer



share|improve this answer











answered Jul 19 at 18:39









slm♦

232k65479649




232k65479649











  • 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 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 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 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 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 at 20:54

















  • 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 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 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 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 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 at 20:54
















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 at 19:45




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 at 19:45




1




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 at 19:54




@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 at 19:54




2




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 at 19:56




@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 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 at 20:53




"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 at 20:53




1




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 at 20:54





@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 at 20:54













 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f457270%2fuse-the-lans-of-one-server-to-access-the-lan-of-another%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay