Use the LANs of one server to access the LAN of another
Clash 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
- 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
- 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 theping 10.0.4.4
command.
IMPORTANT -> These are tests I'm doing on virtual machines.
iptables firewall firewalld iptables-redirect iptables-persistent
add a comment |Â
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
- 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
- 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 theping 10.0.4.4
command.
IMPORTANT -> These are tests I'm doing on virtual machines.
iptables firewall firewalld iptables-redirect iptables-persistent
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
add a comment |Â
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
- 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
- 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 theping 10.0.4.4
command.
IMPORTANT -> These are tests I'm doing on virtual machines.
iptables firewall firewalld iptables-redirect iptables-persistent
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
- 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
- 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 theping 10.0.4.4
command.
IMPORTANT -> These are tests I'm doing on virtual machines.
iptables firewall firewalld iptables-redirect iptables-persistent
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
add a comment |Â
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
add a comment |Â
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.
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
add a comment |Â
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
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 runtcpdump -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 - usetcpdump
to see if the ping traffic is getting to the VM. I showed thetcpdump
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
 |Â
show 2 more comments
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.
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
add a comment |Â
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.
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
add a comment |Â
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.
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.
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
add a comment |Â
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
add a comment |Â
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
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 runtcpdump -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 - usetcpdump
to see if the ping traffic is getting to the VM. I showed thetcpdump
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
 |Â
show 2 more comments
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
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 runtcpdump -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 - usetcpdump
to see if the ping traffic is getting to the VM. I showed thetcpdump
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
 |Â
show 2 more comments
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
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
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 runtcpdump -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 - usetcpdump
to see if the ping traffic is getting to the VM. I showed thetcpdump
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
 |Â
show 2 more comments
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 runtcpdump -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 - usetcpdump
to see if the ping traffic is getting to the VM. I showed thetcpdump
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
 |Â
show 2 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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