LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 12-09-2021, 04:26 PM   #1
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Rep: Reputation: Disabled
OpenVPN Server routing between multiple interfaces


Hi, I am looking for help with a OpenVPN setup where I have problems to reach targets on a second network interface of the OpenVPN server.

Please see attached picture which shows the IP addresses of the clients and network interfaces of the OpenVPN Server.

VPN:
server: 10.8.0.1
client1: 10.8.0.2
client2: 10.8.0.3
client3: 10.8.0.4
client4: 10.8.0.5
client5: 10.8.0.6

eth0 (VPN Server):
172.31.4.115 (route for client1)
172.31.10.54 (route for client2)
172.31.14.166 (route for client3)

eth1 (VPN Server):
172.31.15.5 (route for client4)
172.31.7.18 (route for client5)
...

I am using IP tables and SNAT to forward the traffic based on source IP (client) to the specific IP in the OpenVPN server.
This works without any problems for client1,client2,client3 where the destionation interface is eth0.
For client4,client5 where the destination interface is eth1 I am unable to route the traffic or even ping the IP.

I am really wondering what could be the reason.

IP tables on the server:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
/usr/sbin/iptables -t nat -F
#
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.2 -j SNAT --to 172.31.4.115
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.4.115 --dport 22 -j DNAT --to-dest 10.8.0.2:22
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.4.115 --dport 80 -j DNAT --to-dest 10.8.0.2:80
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.4.115 --dport 44158 -j DNAT --to-dest 10.8.0.2:44158
#
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.3 -j SNAT --to 172.31.14.177
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.14.177 --dport 22 -j DNAT --to-dest 10.8.0.3:22
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.14.177 --dport 80 -j DNAT --to-dest 10.8.0.3:80
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.14.177 --dport 44158 -j DNAT --to-dest 10.8.0.3:44158
#
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.4 -j SNAT --to 172.31.10.54
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.10.54 --dport 22 -j DNAT --to-dest 10.8.0.4:22
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.10.54 --dport 80 -j DNAT --to-dest 10.8.0.4:80
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.10.54 --dport 44158 -j DNAT --to-dest 10.8.0.4:44158
#
/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.5 -j SNAT --to 172.31.15.5
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.15.5 --dport 22 -j DNAT --to-dest 10.8.0.5:22
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.15.5 --dport 80 -j DNAT --to-dest 10.8.0.5:80
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -d 172.31.15.5 --dport 44158 -j DNAT --to-dest 10.8.0.5:44158
ip address:
Code:
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 02:24:9f:96:87:b2 brd ff:ff:ff:ff:ff:ff
    inet 172.31.8.247/20 brd 172.31.15.255 scope global dynamic eth0
       valid_lft 3012sec preferred_lft 3012sec
    inet 172.31.4.115/20 brd 172.31.15.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 172.31.10.54/20 brd 172.31.15.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 172.31.14.177/20 brd 172.31.15.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::24:xxxx:fe96:87b2/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 02:9e:13:ba:cd:d2 brd ff:ff:ff:ff:ff:ff
    inet 172.31.15.5/20 brd 172.31.15.255 scope global dynamic eth1
       valid_lft 3193sec preferred_lft 3193sec
    inet 172.31.7.18/20 brd 172.31.15.255 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet 172.31.8.7/20 brd 172.31.15.255 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet 172.31.4.163/20 brd 172.31.15.255 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::9e:xxxx:feba:cdd2/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 02:70:77:02:4c:3a brd ff:ff:ff:ff:ff:ff
    inet 172.31.3.55/20 brd 172.31.15.255 scope global dynamic eth2
       valid_lft 2972sec preferred_lft 2972sec
    inet 172.31.7.165/20 brd 172.31.15.255 scope global secondary eth2
       valid_lft forever preferred_lft forever
    inet 172.31.3.63/20 brd 172.31.15.255 scope global secondary eth2
       valid_lft forever preferred_lft forever
    inet 172.31.11.150/20 brd 172.31.15.255 scope global secondary eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::70:xxxx:fe02:4c3a/64 scope link
       valid_lft forever preferred_lft forever
11: 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 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::70c0:xxxx:ca81:1bf4/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
iptables --list -vv -n
Code:
Chain PREROUTING (policy ACCEPT 492 packets, 32971 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.4.115         tcp dpt:22 to:10.8.0.2:22
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.4.115         tcp dpt:80 to:10.8.0.2:80
   25  1500 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.4.115         tcp dpt:44158 to:10.8.0.2:44158
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.14.177        tcp dpt:22 to:10.8.0.3:22
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.14.177        tcp dpt:80 to:10.8.0.3:80
   41  2460 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.14.177        tcp dpt:44158 to:10.8.0.3:44158
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.10.54         tcp dpt:22 to:10.8.0.4:22
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.10.54         tcp dpt:80 to:10.8.0.4:80
   66  3960 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.10.54         tcp dpt:44158 to:10.8.0.4:44158
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.15.5          tcp dpt:22 to:10.8.0.5:22
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.15.5          tcp dpt:80 to:10.8.0.5:80
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            172.31.15.5          tcp dpt:44158 to:10.8.0.5:44158

Chain INPUT (policy ACCEPT 22 packets, 2308 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 315 packets, 23706 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 447 packets, 31626 bytes)
 pkts bytes target     prot opt in     out     source               destination
   32  2016 SNAT       all  --  *      *       10.8.0.2             0.0.0.0/0            to:172.31.4.115
   21  1284 SNAT       all  --  *      *       10.8.0.3             0.0.0.0/0            to:172.31.14.177
   77  4695 SNAT       all  --  *      *       10.8.0.4             0.0.0.0/0            to:172.31.10.54
  322 21156 SNAT       all  --  *      *       10.8.0.5             0.0.0.0/0            to:172.31.15.5
route -n
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.0.1      0.0.0.0         UG    0      0        0 eth0
0.0.0.0         172.31.0.1      0.0.0.0         UG    10001  0        0 eth1
0.0.0.0         172.31.0.1      0.0.0.0         UG    10002  0        0 eth2
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.31.0.0      0.0.0.0         255.255.240.0   U     0      0        0 eth0
172.31.0.0      0.0.0.0         255.255.240.0   U     0      0        0 eth1
172.31.0.0      0.0.0.0         255.255.240.0   U     0      0        0 eth2
from client4 and client5 i can ping 172.31.4.115,172.31.14.177,172.31.10.54 but I am not able to ping 172.31.15.5 which is on eth1...

What am I missing? I tried for 3 days now and cannot get it working. I would like to avoid setting up bridging...
I think it has something to do with the routes. Any advise?


UPDATE:

I did some more research and enabled logging for iptables. for pings to ips belonging to eth0 I get the logs
Code:
Dec 10 09:58:12 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44598 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=1
Dec 10 09:58:13 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44651 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=2
Dec 10 09:58:14 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44894 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=3
Dec 10 09:58:15 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=44962 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=4
Dec 10 09:58:16 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45087 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=5
Dec 10 09:58:17 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45194 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=6
Dec 10 09:58:18 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45202 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=7
Dec 10 09:58:19 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45265 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=8
Dec 10 09:58:20 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45461 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=9
Dec 10 09:58:21 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45464 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=10
Dec 10 09:58:22 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45512 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=11
Dec 10 09:58:23 ip-172-31-8-247 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.5 DST=172.31.10.54 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=45726 DF PROTO=ICMP TYPE=8 CODE=0 ID=2288 SEQ=12
But if I want to ping ips on eth1 nothing gets logged, so it seems its not even hitting the iptables?
Attached Thumbnails
Click image for larger version

Name:	OpenVPN Server.png
Views:	50
Size:	42.0 KB
ID:	37816  

Last edited by Flowsen; 12-10-2021 at 04:02 AM. Reason: update
 
Old 12-12-2021, 01:30 AM   #2
ferrari
LQ Guru
 
Registered: Sep 2003
Location: Auckland, NZ
Distribution: openSUSE Leap
Posts: 5,792

Rep: Reputation: 1140Reputation: 1140Reputation: 1140Reputation: 1140Reputation: 1140Reputation: 1140Reputation: 1140Reputation: 1140Reputation: 1140
I haven't digested your network topology, but wonder if the server needs to advertise "push routes"....?

https://openvpn.net/community-resour...server-subnet/
https://forums.openvpn.net/viewtopic.php?t=9055
https://community.openvpn.net/openvp...-0-gaNycGzNCH0

Sorry if I'm on the wrong track here. I use OpenVPN extensively in a production network I manage (connecting to remote sites) but NAT is not employed as part of that solution.
 
Old 12-14-2021, 12:19 PM   #3
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Original Poster
Rep: Reputation: Disabled
Thanks for your reply. As far as for my understanding the push routes will only be sent to the client to update the routing table.
Since I was doing a ping 172.31.15.5 -I tun0 directely to the VPN I think I do not need that route (at least for testing)

I am a step further now, previously I was not getting iptable logging for 172.31.15.5 on eth1. It turned out, that this was an issue with RHEL (Amazon Linux):
https://access.redhat.com/solutions/53031

after setting net.ipv4.conf.all.rp_filter to 2 i was able to see the logging in itables. But still I was not able to ping it. I think now I am missing some iptables forwarding rules to receive the packages that I have sent to that eth1 interface
 
Old 12-16-2021, 06:17 AM   #4
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
Just as a tentative approach: what's with the server 10.8.0.1? Is this the same as the openvpn itself?
 
Old 12-16-2021, 06:30 AM   #5
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Original Poster
Rep: Reputation: Disabled
Yes, 10.8.0.1 is the OpenVPN server tun0 device. All devices within 10.8.0.x can ping each other.
 
Old 12-16-2021, 06:34 AM   #6
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
I might be missing something, but what does this even have to do with the vpn service if the clients and the vpn server are on the same network?
This seems to be solely a routing problem, nothing to do with vpn, does it?

Last edited by vincix; 12-16-2021 at 07:40 AM.
 
Old 12-16-2021, 07:03 AM   #7
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Original Poster
Rep: Reputation: Disabled
Sorry, if my answer was not that clear. 10.0.0.x are the IPs of the VPN tunnel.
The VPN Server itself hast multiple network interfaces with multiple IPs each:

eth0 (VPN Server):
172.31.4.115
172.31.10.54
172.31.14.166

eth1 (VPN Server):
172.31.15.5
172.31.7.18

so routing between the VPN clients and to all IPs on eth0 works, its just the seconde network interface eth1 that is not reachable from anywhere (expect from the server itself)
 
Old 12-16-2021, 07:49 AM   #8
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
Why do different clients connect to different interfaces on the vpn?
 
Old 12-16-2021, 08:41 AM   #9
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Original Poster
Rep: Reputation: Disabled
For a specific reason each client needs to have a separate public IP address. On the other hand there is a limitation in AWS cloud of having 3 IP addresses for each network interface, therefore I needed to add additional network interface.
 
Old 12-17-2021, 02:01 AM   #10
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
You're trying to achieve interconnectivity between the clients only, if I understand this correctly, right? If that's the case, may I ask why you're using NAT at all? Why not simply forwarding?
 
Old 12-17-2021, 02:18 AM   #11
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Original Poster
Rep: Reputation: Disabled
I have interconnectivity between the VPN clients. Each client within 10.8.0.x can reach each other. But thats just due to the fact that I enabled IPv4 forwarding with "echo 1 > /proc/sys/net/ipv4/ip_forward". I would even restrict this with iptables deny rules because this is not needed at all. But since I am still trying to solve my main problem I did not apply any deny rules so far.

I think the image attached to my original post is still the best way to understand what should be achieved.

client1 VPN IP 10.8.0.2 should connect through the servers private IP 172.31.4.115 to the internet
client2 VPN IP 10.8.0.3 should connect through the servers private IP 172.31.10.54 to the internet
client3 VPN IP 10.8.0.4 should connect through the servers private IP 172.31.14.166 to the internet

this works as expected, but all clients that should use servers private IP located on the second network interface (eth1) will fail:
client4 VPN IP 10.8.0.5 should connect through the servers private IP 172.31.15.5 to the internet
...

I am not 100% sure, but I think beside of the ipv4 forwarding, in order to route the internet traffic through the servers private IP I still need some kind of SNAT, DNAT or MASQUERADE. And to be clear this solution works for client1,2,3 but not for 4,5....
 
Old 12-17-2021, 02:32 AM   #12
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
I'm not ill-meant, but I have to say - this is actually the first time you've actually stated what you're trying to achieve.
This "I am using IP tables and SNAT to forward the traffic based on source IP (client) to the specific IP in the OpenVPN server." is misleading.

So you simply want to have internet access for the clients. Indeed, then you need SNAT (to specify the exact ip you want to use as a source ip when reaching the internet) or MASQUERADE (the os computes automatically what ip it should use, which is usually the default one).

You normally use DNAT when you want to access network resources directly from outside. So I'm not sure what you're trying to achieve by that there. Maybe you can explain your intention?

Code:
DNAT       tcp  --  *      *       0.0.0.0/0            172.31.4.115         tcp dpt:22 to:10.8.0.2:22
This means anyone who tries to connect to ip destination 172.31.4.115 and port 22 will be redirected to ip 10.8.0.2 and port 22.
So that basically translates into: if you want to connect to the ssh port on the openvpn server (on the ip 172.31.4.115) you're going to be redirect to the client1's ip and ssh port. That doesn't seem to make much sense to me at first glance.

One more thing, what's this ip "172.31.14.177"? You haven't mentioned it anywhere.

Last edited by vincix; 12-17-2021 at 02:40 AM.
 
Old 12-17-2021, 02:43 AM   #13
Flowsen
LQ Newbie
 
Registered: Sep 2011
Posts: 29

Original Poster
Rep: Reputation: Disabled
Yes you are absolutely right with all your assumptions

Quote:
This means anyone who tries to connect to ip destination 172.31.4.115 and port 22 will be redirected to ip 10.8.0.2.
So that basically translates into: if you want to connect to the ssh port on the openvpn server (on the ip 172.31.4.115) you're going to be redirect to the client1's ip and ssh port. That doesn't seem to make much sense to me at first glance.
Yes that's correct, and same applies for port 80 and 44158. To be clear, I know that exposing port 22 to the public is not a good idea but there is a firewall restricting access to port 22 only to specific IPs (in front of the server)

Quote:
One more thing, what's this ip "172.31.14.177"? You haven't mentioned it anywhere.
well paid attention, this was just a typo from me. 172.31.14.177 is the correct one (mentioned as 172.31.14.166) in my previous post
 
Old 12-17-2021, 03:03 AM   #14
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
Ok, I see. I still don't really understand where the problem lies. Maybe you can create a logging rule for client4's ip (you haven't shown the snat rule corresponding to client5's traffic, but I'm guessing it's the same) before you do the actual SNAT.
Code:
iptables -t nat -I POSTROUTING RULE_NUMBER -s 10.8.0.5 -j LOG --log-prefix "CLIENT4 SNAT: " --log-level 7
(you have to choose the correct rule number. You can see that exactly with iptables -t nat -vnL POSTROUTING --line-numbers, but you probably already know that)


I see the gateway is 172.31.0.1.
What IP on the server belong to the same subnet as the gateway?
(ip route show and ip address show are more legible )
later edit: only later did I see the output of 'ip address show'.

Last edited by vincix; 12-17-2021 at 05:41 AM.
 
Old 12-18-2021, 09:33 AM   #15
vincix
Senior Member
 
Registered: Feb 2011
Distribution: Ubuntu, Centos
Posts: 1,240

Rep: Reputation: 103Reputation: 103
What I also find weird is that you all assigned IPs on various interfaces belong to the same subnet. You normally have different interfaces belonging to different subnets. I think this might screw up your routing, but I still don't understand exactly how.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
iptables multiple interfaces same subnet to multiple vlan interfaces krobinson Linux - Server 3 04-22-2015 04:25 AM
Error When converting Routing OpenVPN to bridge mode openvpn danmartinj Linux - Software 0 11-06-2009 09:23 AM
Routing between interfaces? cryptical Linux - Networking 13 08-18-2004 07:29 AM
Routing Between Virtual Interfaces on Web Server Louie55 Linux - Networking 2 02-20-2004 09:17 AM
Problem with routing between interfaces Kostko Linux - Networking 6 12-01-2003 01:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 04:43 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration