Interface not accepting connections

General Help
1

I am having an issue with my LAN interface not accepting any communication. The WAN interface accepts all communication for the SIP phones, for SSH and the GUI. The LAN interface pings without any issue so it is mechanically up but the GUI is a page not found reply. I am not sure when the problem started as our primary interface used is the WAN (em2). I have recently done an upgrade from 11 to 12 without any major issues and do not believe this to be the cause but could be wrong. Below is the ifconfig (minus IP addresses) any thoughts or potential ideas are appreciated.

ifconfig
em1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Mask:255.255.xxx.xxx
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:464901 errors:0 dropped:0 overruns:0 frame:0
TX packets:10954 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:68800845 (65.6 MiB) TX bytes:2279239 (2.1 MiB)
Interrupt:16

em2 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Mask:255.255.255.xxx
inet6 addr: Scope:Global
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:84573940 errors:0 dropped:0 overruns:0 frame:0
TX packets:83622386 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18448177189 (17.1 GiB) TX bytes:19078327612 (17.7 GiB)
Interrupt:17

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:92490309 errors:0 dropped:0 overruns:0 frame:0
TX packets:92490309 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22870092143 (21.2 GiB) TX bytes:22870092143 (21.2 GiB)

2

Sounds like your Apache config has forgotten how to listen on the LAN interface.

3

I would have suspected the same thing but the ssh and the SIP authentication are both also not working.

4

… and in the right light, the sky looks orange. :smile:

Apache, the software website that allows you to configure the system is not set up to listen on the local network. The fact that SIP and SSH are working (two completely different programs) are working is actually the proof that your APACHE configuration is horked.

5

I think you may have misread my last post. The SSH and SIP are NOT working on the em1. There is no communication that is working on the em1 port but all protocols are working correctly on the em2 port.

6

netstat can help you here, for the man page:-

man netstat

start with

netstat -auntp
netstat -r

it should identify all running servicesa and what interfaces they are listening on (0.0.0.0 means the are listening on all interfaces identified by netstat -i) , also it will print your routing tables.

Next needed information can be derived from

iptables -nL

to make sure you are not blocking any traffic to/from any network of interest.

Correct any problems you find and finally

tcpdump -nnvv -i em1

To confirm you fixed things and traffic is actually flowing on em1

7

The nestat -i defines both the WAN em2 interface as well as the LAN em1 interface. The netstat -auntp shows:

tcp 0 0 :::80 :::* LISTEN 2967/httpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1907/sshd
udp 0 0 0.0.0.0:5060 0.0.0.0:* 39317/asterisk

Even with all of these listening and Fail2Ban with the local scope and the static ip subnets in an allow status I am not able to ssh, authenticate or open a browser with the LAN IP address. I thought there may be a chance of IP conflict do to recent network modifications. So I administratively took down the em1 and the ping was host not found. So no conflict but still not able to use that port.

8

you didn’t share your iptables -Ln so just

service iptables stop and from the prospective client, for httpd

nmap -p 80 yourmachine

for sip

nmap -sU -p 5060 yourmachine

should give you a clue. If you have not restricted sshd or httpd then you should be able to complete a connection if it is properly routed, then “tcpdump” will show bidirectional traffic

9

Noticed that my ifconfig was not showing the IPv4 address so I attempted a network restart and it seems that the ipcal is having an issue with my subnet mask. The nework restart command gives an output of:
service network restart
Shutting down interface em1: [ OK ]
Shutting down interface em2: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface em1: ipcalc: bad netmask: 255.255.252.000
ipcalc: bad netmask: 255.255.252.000
ipcalc: bad netmask: 255.255.252.000
Determining if ip address 172.16.10.5 is already in use for device em1…
Error: an inet prefix is expected rather than “172.16.10.5/”.
Error adding address 172.16.10.5 for em1.
bind: Cannot assign requested address
[ OK ]
Bringing up interface em2: Determining if ip address xxx.xxx.xxx.xxx is already in use for device em2…
[ OK ]
I am not sure what would cause this as the subnet mask is a good mask and is functional for every other internal device.

11

After a modification of the subnet to a working subnet of 255.255.252.0, I am no longer getting the error of bad subnet. I am still unable to ssh into the LAN interface, access the GUI or authenticate an extension locally. Thought the WAN facing interface is working without any issues. I have ensured that the FAIL2BAN is not blocking me and interface is electrically functional.

12

you didn’t share your iptables -Ln so just

service iptables stop and from the prospective client, for httpd

nmap -p 80 yourmachine

for sip

nmap -sU -p 5060 yourmachine

should give you a clue. If you have not restricted sshd or httpd then you should be able to complete a connection if it is properly routed, then “tcpdump” will show bidirectional traffic

13

What do you have entered as the gateway for your em1 (LAN)?
Also that subnet slash “/” after the 172.16.10.5 looks suspicious - maybe a typo?

14

[root@localhost ~]# iptables -Ln
iptables: No chain/target/match by that name.

[root@localhost ~]# nmap -p 80 172.16.10.5

Starting Nmap 5.51 ( http://nmap.org ) at 2015-02-23 13:50 EST
Nmap scan report for 172.16.10.5
Host is up (0.000073s latency).
PORT STATE SERVICE
80/tcp open http

root@localhost ~]# nmap -sU -p 5060 172.16.10.5

Starting Nmap 5.51 ( http://nmap.org ) at 2015-02-23 13:53 EST
Nmap scan report for 172.16.10.5
Host is up.
PORT STATE SERVICE
5060/udp open|filtered sip

Nmap done: 1 IP address (1 host up) scanned in 7.65 seconds

As for the gateway it is 172.16.10.1 and the net mask is not a typo. It is done intentionally.

15

Oops , typo

should be iptables -nL (or -n -L , use man iptables first :wink: )

so from that host both SIP and a webserver are available and in fact that interface IS accepting connections, you just proved it :slight_smile:

tcpdump -nnvv port 80

while connecting . . .

16

Did you include the slash and CIDR number as part of the static ip entry - or is this “172.16.10.5/” result being generated by the system?

17

[root@localhost etc]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all – 1.0.0.0/8 0.0.0.0/0
DROP all – 121.0.0.0/8 0.0.0.0/0
DROP all – 123.0.0.0/8 0.0.0.0/0
DROP all – 94.0.0.0/8 0.0.0.0/0
DROP all – 117.0.0.0/8 0.0.0.0/0
DROP all – 85.0.0.0/8 0.0.0.0/0
DROP all – 91.0.0.0/8 0.0.0.0/0
DROP all – 109.0.0.0/8 0.0.0.0/0
DROP all – 194.0.0.0/8 0.0.0.0/0
DROP all – 2.0.0.0/8 0.0.0.0/0
DROP all – 5.0.0.0/8 0.0.0.0/0
DROP all – 31.0.0.0/8 0.0.0.0/0
DROP all – 37.0.0.0/8 0.0.0.0/0
DROP all – 108.59.13.7 0.0.0.0/0
DROP all – 46.0.0.0/8 0.0.0.0/0
DROP all – 79.0.0.0/8 0.0.0.0/0
DROP all – 80.0.0.0/8 0.0.0.0/0
DROP all – 82.0.0.0/8 0.0.0.0/0
DROP all – 83.0.0.0/8 0.0.0.0/0
DROP all – 85.0.0.0/8 0.0.0.0/0
DROP all – 86.0.0.0/8 0.0.0.0/0
DROP all – 87.0.0.0/8 0.0.0.0/0
DROP all – 91.0.0.0/8 0.0.0.0/0
DROP all – 92.0.0.0/8 0.0.0.0/0
DROP all – 128.0.0.0/16 0.0.0.0/0
DROP all – 132.186.0.0/16 0.0.0.0/0
DROP all – 141.0.0.0/8 0.0.0.0/0
DROP all – 176.0.0.0/8 0.0.0.0/0
DROP all – 192.40.69.0/24 0.0.0.0/0
DROP all – 192.58.29.0/24 0.0.0.0/0
DROP all – 192.103.14.0/24 0.0.0.0/0
DROP all – 192.126.120.0/23 0.0.0.0/0
DROP all – 192.33.102.0/24 0.0.0.0/0
DROP all – 192.33.172.0/24 0.0.0.0/0
DROP all – 193.33.172.0/24 0.0.0.0/0
DROP all – 193.0.0.0/8 0.0.0.0/0
DROP all – 62.0.0.0/8 0.0.0.0/0
DROP all – 81.0.0.0/8 0.0.0.0/0
DROP all – 84.0.0.0/8 0.0.0.0/0
DROP all – 89.0.0.0/8 0.0.0.0/0
DROP all – 90.0.0.0/8 0.0.0.0/0
DROP all – 139.0.0.0/8 0.0.0.0/0
DROP all – 147.83.0.0/16 0.0.0.0/0
DROP all – 147.84.0.0/16 0.0.0.0/0
DROP all – 147.91.0.0/16 0.0.0.0/0
DROP all – 194.0.0.0/8 0.0.0.0/0
DROP all – 195.0.0.0/8 0.0.0.0/0
DROP all – 212.0.0.0/8 0.0.0.0/0
DROP all – 213.0.0.0/8 0.0.0.0/0
DROP all – 217.0.0.0/8 0.0.0.0/0
DROP all – 58.0.0.0/8 0.0.0.0/0
DROP all – 59.0.0.0/8 0.0.0.0/0
DROP all – 60.0.0.0/8 0.0.0.0/0
DROP all – 61.0.0.0/8 0.0.0.0/0
DROP all – 165.228.0.0/16 0.0.0.0/0
DROP all – 165.229.0.0/16 0.0.0.0/0
DROP all – 168.140.0.0/16 0.0.0.0/0
DROP all – 202.0.0.0/8 0.0.0.0/0
DROP all – 203.0.0.0/8 0.0.0.0/0
DROP all – 210.0.0.0/8 0.0.0.0/0
DROP all – 211.0.0.0/8 0.0.0.0/0
DROP all – 218.0.0.0/8 0.0.0.0/0
DROP all – 219.0.0.0/8 0.0.0.0/0
DROP all – 220.0.0.0/8 0.0.0.0/0
DROP all – 221.0.0.0/8 0.0.0.0/0
DROP all – 222.0.0.0/8 0.0.0.0/0
DROP all – 178.0.0.0/8 0.0.0.0/0
DROP all – 122.0.0.0/8 0.0.0.0/0
DROP all – 66.199.224.0/19 0.0.0.0/0
DROP all – 162.212.180.0/22 0.0.0.0/0
DROP all – 115.0.0.0/8 0.0.0.0/0
DROP all – 183.0.0.0/8 0.0.0.0/0
DROP all – 188.0.0.0/8 0.0.0.0/0
DROP all – 42.0.0.0/8 0.0.0.0/0
DROP all – 103.0.0.0/8 0.0.0.0/0
DROP all – 101.0.0.0/8 0.0.0.0/0
DROP all – 111.0.0.0/8 0.0.0.0/0
DROP all – 189.0.0.0/8 0.0.0.0/0
DROP all – 192.99.0.0/16 0.0.0.0/0
DROP all – 113.0.0.0/8 0.0.0.0/0
ACCEPT all – xxx.xxx.xxx.xxx 0.0.0.0/0
ACCEPT all – xx.xxx.xxx.xxx/28 0.0.0.0/0
ACCEPT tcp – xxx.xxx.xxx.xxx 0.0.0.0/0 tcp dpt:22
DROP all – 74.87.121.99 0.0.0.0/0
ACCEPT all – 0.0.0.0/0 0.0.0.0/0
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED
ACCEPT all – 128.136.224.250 0.0.0.0/0
ACCEPT all – 128.136.224.251 0.0.0.0/0
ACCEPT all – 128.136.224.252 0.0.0.0/0
ACCEPT tcp – 172.16.8.0/22 0.0.0.0/0 tcp dpt:80
ACCEPT tcp – 172.16.8.0/22 0.0.0.0/0 tcp dpt:22
ACCEPT tcp – 127.0.0.1 0.0.0.0/0 tcp dpt:3306
fail2ban-SSH tcp – 0.0.0.0/0 0.0.0.0/0
fail2ban-SIP all – 0.0.0.0/0 0.0.0.0/0
ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 udp
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:58080
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:55050
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:8008
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain fail2ban-SIP (1 references)
target prot opt source destination
RETURN all – 0.0.0.0/0 0.0.0.0/0

Chain fail2ban-SSH (1 references)
target prot opt source destination
RETURN all – 0.0.0.0/0 0.0.0.0/0

18

I would start over after

service iptables stop

your

ACCEPT all – 0.0.0.0/0 0.0.0.0/0

kind of blows out anything afterwards and the whole thing is kind of muddy. But if you know what you are doing , then it should work . Check for two way traffic on port 80 as I have several times suggested.

19

Thank you everyone for the assistance but it seems that due to some improperly configured switches was causing some of my issue after the bad subnet resolution. After a direct connect to the em1 the interface seems to be working as it should be.