SG-1100 Port Forwarding
-
having an odd issue here, and I've gone through all the guides I can find. So I'm coming from a background of managing Dell SonicWall and good old fashioned IPTables, so there was a small learning curve with PFSense, but I think this is beyond a learning curve.
So here's the scenerio, want to have port 9758 exposed externally, and forward to 22 on an internal host. So, went into Firewall > NAT and created a NAT entry with the Destination being WAN address, Destination Port Range being 9758, Redirect target IP being an internal IP, and the Redirect target port being 22. I haven't enabled NAT reflection because quite frankly, I'm not looking for that, simply external to internal Port Forwarding, not internal and hairpin back. Under Filter rule association I let it create the rule.
So, what I'm getting is exactly nothing, no connection, no connection refused, nothing. Looking in PFSense in the rule, I can see that the states for port 9758 are CLOSED:SYN_SENT, which tells me that the internal client is not responding. So, since I have my second firewall still running on a seperate public IP, I check out the Port Forwarding there and it still is working as expected, and that is my very old Dell SonicWall.
So now, not that this should actually matter or make any difference, I went to my internal server and set it's default GW to the PFSense appliance, and tried the connection again. Now, I get a TIME_WAIT:TIME_WAIT, which is really confusing me as the gateway shouldn't actually matter because the return path doesn't care about the GW, it returns over the established path. So now, I'm really confused on what's going on here. Now before anyone yells about the GW not mattering comment, I want to prefix that this SG-1100 is replacing a generic Ubuntu box that was running IPTables, and all of this worked without having to modify the default GW of my internal server, as expected. The generic box had same IP and such, so I know it's not some odd config I stashed away somewhere, believe me I thought that was the case originally.
So, I'm at an empasse on how to get this to work.
-
It's usually pretty easy to troubleshoot a port-forward. First off, I assume you have gone through this document?
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
This covers literally every scenario.
Do a packet capture on WAN to see if the traffic hits WAN at all. Do the same on LAN to see the traffic forwarded. If those both work, then your issue is with the client.
-
@KOM Itotally agree that usually this shouldn't be difficult. So, doing a bunch of TCP Dumps and looking over Wireshark, I'm just as baffled as I was before the dumps. Here's a basic layout, where PF is the PFSense appliance, SW is my SonicWall, and Internal is my server with SSH running.
When I connect through the SW, everything is fine. The external port is 9758, which is forwarded to 22 on Internal. Packet trace shows all is well, and I'm SSH'd from my laptop that is connected inside the network. Externally I am using my cell phone.
When I try to connect through Pf, well, no joy, and here's the packet capture.
174.197.20.36 is my cell phone, and 10.27.200.1 Internal. So, not sure why it's failing through PF but not through SW. Here's a third capture where I set the gateway of Internal to PF, and to me I'm just as confused as before.
The only conclusion I can come up with is PF is blocking the return, as you can see the session starts the buildup.
Thoughts?
-
If you have both the sonicwall and pfSense in place at the same time, what is the default gateway set to on 10.27.200.1?
-
@Derelict when not testing its set to SW. odd thing, I set the gateway to PF last night and forgot to set it back, and as you saw from the capture the forwarding didn’t work, but I just tried it and it’s working. The only thing I’ve done differently is let the gateway point to PF for several hours. I’m truly stumped.
-
Sounds like you had asymmetric routing going on. If changing the gateway on the target server was not working correctly, that would be a function of the server itself, not either of the firewalls.
-
@Derelict Yeah, it does sound like that a lot. Another oddity is that other items on the firewall, like package manager and such wasn't working last night (kept saying could find some sqlite files) but this morning, all is good. It seems that the firewall needed to be up and online for a couple of days before things started working as expected.
-
Except whatever was taking a couple of days is nothing on the firewall. It most certainly needs reliable internet access and DNS, etc to check for and install updates/packages though.
-
@Derelict very weird indeed, I had clients using it and it's using my internal DNS, so not sure what was going on.
