How can I tell who is blocking my ports after removing PF, IPFILTER and IPFW

If there is no firewall activated on my FreeBSD installation, who is in charge of filtering the data from and to my ports?

I am trying to set up a VPN IPsec server. I used this very helpful post of rolfheinrich. Now I'm scanning this local machine (not DMZ yet)from a different local machine (under the same NAT) and the only open port I see is SSH.

I used the kldstat command to see what modules loaded with the kernel and I can't see any firewall loading. I recompiled the kernel leaving PF out, I also removed any firewall options from rc.conf, so theoretically my ports should be exposed. I know it's not safe, but for now I'd like to focus on the VPN server and later add all the security I need back on. If I use netstat I have the isakmp and sae-urn daemons running on my local IP, so in theory I should be able to connect. I tried it from multiple devices and it is not working. I figured that until I will be able to see ports UDP 4500, UDP 500 and TCP 1701 open I won't continue trying to connect to this server.

Any suggestions, links, commands and tools would be appreciated.

Thanks.
 
L2TP utilizes UDP port 1701, and not TCP 1701. In addition, the L2TP traffic doesn't go directly through the LAN interface, but it is part of the IPsec transport on port 500 or 4500.

How did you check that the UDP ports 500 and 4500 are blocked?
 
@rolfheinrich, thank you for your answer. The way I checked for open ports was via an nmap scanner from a Linux machine with nmap -T Aggressive -v -n <FreeBSD_Server_Local_IP_Address>. I can see SSH on port 22 open, but nothing else is open (even with no firewall set up in my rc.conf file). Then, I tried to connect via an iPhone SSH client with no result.

I was hoping to disable all firewalls first, get the L2TP server working and then enable and edit my firewall rules. What do you suggest?

Thanks much.
-nactus
 
Last edited by a moderator:
Please try the port scan again, this time using $ sudo nmap --allports -sU -v -n <FreeBSD_Server_Local_IP_Address>.
 
I'd advise to run sockstat -4l on the server, then check which ports are being used for listening. After that you could try using telnet to connect to these ports from another location.

My guess is that those processes bound to localhost instead of your public interface, as such you can't access them from a remote location.
 
rolfheinrich said:
Please try the port scan again, this time using $ sudo nmap --allports -sU -v -n <FreeBSD_Server_Local_IP_Address>.

@rolfheinrich, now I see:
Code:
123/udp  open          ntp
500/udp  open          isakmp
514/udp  open|filtered syslog
4500/udp open|filtered nat-t-ike

What I did was I enabled the firewall in the rc.conf and wrote an ipfw add allow in and ipfw add allow out command to the /usr/local/etc/ipfw.rules file, so the firewall is completely transparent.

I also ran a scan from a Mac computer and it shows ports TCP 22 and 5006 open. Nether of those two ports show up in the nmap scan.

So, I suppose I will try to expose the server and try to connect to it from an iOS mobile device to see what happens. Quick question, if I have two NATs and I place the FreeBSD server into the first one, would I be able to connect to the L2TP server from NAT2? (I guess that would make for a completely different question :)). The idea is that I'd like to connect with my phone and one of my computers to the same VPN tunnel and (say) share some files over this VPN. Thanks much for your help.

I'd advice to run sockstat -4l on the server, then check which ports are being used for listening. After that you could try using telnet to connect to these ports from another location.

My guess is that those processes bound to localhost instead of your public interface, as such you can't access them from a remote location.

@ShelLuser I did and I can see mpd5, racoon and sshd as processes listening on several ports. Now I realized that some ports are marked with "*" and others aren't. What is the difference? Are the ones marked with a "*" exposed?
 
Last edited by a moderator:
nactusberrilli said:
...
Quick question, if I have two NATs and I place the FreeBSD server into the first one, would I be able to connect to the L2TP server from NAT2? (I guess that would make for a completely different question :)).

Try it! In my setup the server and the clients may sit behind different NATs. If you need to connect more than one clients behind the same NAT at the same time or if you got Windows clients to be connected, then you would need to patch the kernel, see:

http://forums.freebsd.org/showpost.php?p=231620&postcount=86
http://forums.freebsd.org/showpost.php?p=231620&postcount=88
http://forums.freebsd.org/showpost.php?p=231620&postcount=94

If you have more questions on that setup, then it would be perhaps better to add it in the respective HOWTO thread.
 
rolfheinrich said:
L2TP utilizes UDP port 1701, and not TCP 1701. In addition, the L2TP traffic doesn't go directly through the LAN interface, but it is part of the IPsec transport on port 500 or 4500.

How did you check that the UDP ports 500 and 4500 are blocked?


@rolfheinrich, in regards to your previous statement, and after double-checking your tutorial I found this that I think must be taken a look at:

Make sure, that your firewall is open for the TCP port 1701 and the UDP ports 500 and 4500.
Please notice the "TCP port 1701".

Cheers
 
Last edited by a moderator:
I see the problem has already been solved, but just to answer your question:

nactusberrilli said:
@ShelLuser I did and I can see mpd5, racoon and sshd as processes listening on several ports. Now I realized that some ports are marked with "*" and others aren't. What is the difference? Are the ones marked with a "*" exposed?
Whenever a port is marked with an asterisk it means that it's listening on all available devices and addresses, so they should be accessible.
 
Last edited by a moderator:
Thank you both for all the help and all the shared information. Yes, all is set. I am ready to move into the next phase: DMZ the server's IP, and connecting from a 3d network.

Regands
 
Back
Top