Network issues

[dinohrnd]

Hello, we have a problem on ubuntu 18.4 if anyone has the idea please.
Ubuntus 18.4 VM in vmware which has two network card: one in the DMZ and one in the local network, the server can be reached from the internet from the DMZ card IP by port forwarding and can be reached from the local network from the other network card. The problem is after a while the server is no longer reachable and you have to restart.
thank you in advance for your help .

 

[dcbrown73]

One possibility (and likely issue) is a gateway configuration issue could possibly be causing asymmetrical routing issues. Do you have your default gateway properly configured for your DMZ network and any additional static routes required in place for subnets that reside on your internal network adapter?

 

[jpnilson]

As mentioned it might be a default gateway issue. Could be a lot of other things though. If I were troubleshooting this I would start by attempting a console session with the VM. Assuming you can do that I would open a terminal and run some commands
ip a <obtain addresses of my interface>
ping the addresses. If that fails you have some kind of general failure in you vmware installation. If not move on to looking at your route table.
route -n <will give you your current table> You may have to install net tools to use this command.
You should be able to get your default gateway from that command. Try pinging that. If you cant reach that then it could be a physical issue.
If both of those things work I would try pinging and tracing towards the devices that are unable to reach your server. Hope that helps.

 

[dinohrnd]

here is the content of the / etc / network / interafces file configuration

auto lo
iface lo inet loopback

auto ens192
iface ens192 inet static
        address 192.168.71.6
        netmask 255.255.255.0
        gateway 192.168.71.2
        dns-nameservers 192.168.2.232

auto ens224
iface ens224 inet static
        address 192.168.2.48
        netmask 255.255.255.0
#       gateway 192.168.2.2
up route add -net 192.168.4.0/24 gw 192.168.2.80
up route add -net 192.168.10.0/24 gw 192.168.2.80

 

[dinohrnd]

and here is the content of the route -n command

Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.71.2    0.0.0.0         UG    0      0        0 ens192
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 ens192
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 ens224
192.168.2.0     0.0.0.0         255.255.255.0   U     101    0        0 ens224
192.168.4.0     192.168.2.80    255.255.255.0   UG    0      0        0 ens224
192.168.10.0    192.168.2.80    255.255.255.0   UG    0      0        0 ens224
192.168.71.0    0.0.0.0         255.255.255.0   U     0      0        0 ens192
192.168.71.0    0.0.0.0         255.255.255.0   U     100    0        0 ens192

 

[jpnilson]

I think your problem is going to be with the two routes added. With that said do you expect traffic to flow though this system from one network to another? If so have you enabled IP forwarding? I am guessing the two static routes are an attempt to forward traffic to another router. If you are doing things like that you will have to have static routes on the other side. If it were my world I would do something like enabling a simple routing protocol like rip. One thing you might try is temporarily removing the two routes and see if things stablize for you. I also see a DNS server configured. I had assumed you are doing your tests via IP. for the sake of troubleshooting I would stick to IP addresses. When things are failing are you using a testing point that is on the interfaces connected network? Again if you have console access after failure it would be interesting to see the route table at thaat point. Also once you have failure can you ping either of the interfaces while on the network directly connected to those interfaces. It would be interesting to see the output of an ifconfig command on both the source and target devices of a ping test as well as the route -n output when in failure mode