I'm running an Ubuntu server and I have plugged it into my local network. I've modified the /etc/network/interfaces file to look like this:

auto eth3
iface eth3 inet static

The interface comes up and shows the correct info. The network cards at hardware level are blinking and showing traffic. I can ping localhost.

I have run tcpdump on the interface and I'm seeing network traffic coming off card. By all accounts the network is up and running and I don't see any errors.

However, When I try to ping any computers on the network or try to ping back to this computer from other computers it is like it doesn't exist. I've been working with linux servers for 10+ years and never seen anything like this. Anyone have any ideas of what I might check?

ip a output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN   group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:25:90:0a:eb:08 brd ff:ff:ff:ff:ff:ff
3: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:25:90:0a:eb:09 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth3
       valid_lft forever preferred_lft forever
    inet6 fe80::225:90ff:fe0a:eb09/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 
    inet peer scope global tun0
       valid_lft forever preferred_lft forever

ifconfig output:

eth3      Link encap:Ethernet  HWaddr 00:25:90:0a:eb:09  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::225:90ff:fe0a:eb09/64 Scope:Link
          RX packets:1433 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1115 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:179713 (179.7 KB)  TX bytes:128624 (128.6 KB) 
          Interrupt:17 Memory:feae0000-feb00000 

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:590 (590.0 B)  TX bytes:590 (590.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:  P-t-P:  Mask:
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  • tcpdump seeing traffic going out means little. You must see expected traffic going in. – Rui F Ribeiro Feb 27 at 21:00
  • I don't see traffic going out, I see dns requests from router looking for computers on the network. – user70494 Feb 27 at 21:01
  • a router normally does not do DNS requests... – Rui F Ribeiro Feb 27 at 21:02
  • Please add the output of iptables -L -n, ping tests, relevant tcpdump traces, and the output of ip a, ifconfig -a, ethtool eth3 – Rui F Ribeiro Feb 27 at 21:04
  • what is your default gateway? What is the output of ip route? Can you ping the default gateway? Are your interfaces up? What is the output of ip a? – Timothy Pulliam Feb 27 at 21:05

You have an active point-to-point VPN as can be seen by tun0; the VPN might be messing with local connectivity.

Many VPNs use what is know as full tunnel and mess with local connectivity for security reasons e.g. the "problems" you are describing are there by design, they are part of the intended security policy.

If you want to have local traffic, you have to turn off the VPN, but then you lose connectivity from whatever the other side that VPN is talking to.

Also the tun and dropped message packets on diagnostic data is a clue something fishy is going on. Seems that something/some software/a kernel module is dropped packets by design.

  • Good catch, however, I have removed the openvpn service completely with apt remove openvpn and rebooted the system and still do not have network connections. In fact, I'm getting the exact same responses as before. Just don't have the tun0 network device listed. – user70494 Feb 28 at 13:49
  • It is however a strong clue something is amiss /maybe intencionally configured, and that we do not have enough data on this question to work with – Rui F Ribeiro Feb 28 at 13:53
  • Ok, will continue to research the VPN angle and see if maybe there is some configuration somewhere messing with me. I'll post back if I find something there. Thanks – user70494 Feb 28 at 14:38
  • Turns out this server had shorewall setup for the firewall. Someone else set it up and I didn't realize they had the VPN there. ufw wasn't being used so started looking for something else and found shorewall. I turned it off and everything started working instantly. So now need to figure out what is going on there and should be good. Thanks again for pointing out the VPN as it was definitely the issue. – user70494 Feb 28 at 15:13
  • It was the tun and that dropped message in tcpdump to be more precise that were the clues. It had to be firewalling/a kernel module. Added to the answer to illustrate my reasoning. – Rui F Ribeiro Feb 28 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.