I have Lubuntu 14.04 LTS with vsftpd and the lamp stack (apache2, etc.) installed. Everything works fine on the LAN. Externally, the services don't acknowledge connection attempts. I can see packets reaching the machine with tcpdump-i eth0 -A, but the machine doesn't send a corresponding ACK. sudo ufw status reports "Status:inactive". I don't have any rules configured in "iptables"; iptables -L has blank output.

To make matters more confusing, I can use the external WAN IP assigned to that machine and the hostname from inside the network and connections are successful. To use the WAN IP and hostname externally, I get the same behavior of Ubuntu not sending ACK packets.

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0  *               LISTEN      1494/mysqld
tcp        0      0  *               LISTEN      1277/dnsmasq
tcp        0      0    *               LISTEN      984/vsftpd
tcp        0      0    *               LISTEN      977/sshd
tcp        0      0 *               LISTEN      669/cupsd
tcp6       0      0 :::80                   :::*                    LISTEN      2175/apache2
tcp6       0      0 :::22                   :::*                    LISTEN      977/sshd
tcp6       0      0 ::1:631                 :::*                    LISTEN      669/cupsd

Without divulging too much information, the LAN is a class A private 10.x.x.x/22 network. The server has one NIC assigned a static address in the business VLAN. The server's other NIC has a private class C 192.168.x.x/24 static address in the DMZ.

An nmap scan of both internal addresses shows identical output, shown below:

Nmap scan report for 192.168.x.x/10.x.x.x
Host is up (0.0018s latency).
Not shown: 996 closed ports
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
3306/tcp open  mysql
Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds

A scan on the external IP shows all ports as "filtered", meaning nmap didn't get a SYN/ACK or ACK response.

Starting Nmap 5.21 ( http://nmap.org ) at 2015-02-10 06:28     UTC
Host is up.
21/tcp   filtered ftp
22/tcp   filtered ssh
80/tcp   filtered http
3306/tcp filtered mysql

I ended up figuring this out. It wasn't directly a firewall issue. I have two NICs, one for the LAN and another for the DMZ, to which the WAN IP is NAT'ed. The default route was over the LAN. When receiving packets from the internet, the server tried to respond via the default route on the LAN. Disconnecting from the LAN enabled the services to communicate over the internet.

I still need private LAN communication, but I will tackle that later.

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.