Port forwarding: Timeout
my pfsense should work like this:
- ssh: Incoming requests on port 3022 -> forwarding to 10.1.11.175 Port 22
- http: Incoming requests on port 3020 -> forwarding to 10.1.11.175 Port 80
- ldaps: Incoming requests on port 3026 -> forwarding to 10.1.1.1 Port 636
Some screenshots of my configuration (ssh) and system log are attached.
The log shows that all requests are allowed.
In the table under "Diagnostics > States" no entries concerning the above IPs are present.
The problem is, that all connection attempts ended with a timeout:
ssh: connect to host xxx.ddnss.de port 3022: Connection refused
ldap: Connection timed out
Does anyone have an idea?
Sorry for my bad english ;-)
Grimson last edited by
Thanks. I know this site. But I can't figure out where the problem is.
The "Packet Capture" output when I try to conntect via ssh (filter port 3022):
15:27:13.199038 IP 184.108.40.206.40800 > 220.127.116.11.3022: tcp 0 15:27:14.224421 IP 18.104.22.168.40800 > 22.214.171.124.3022: tcp 0 15:27:16.237957 IP 126.96.36.199.40800 > 188.8.131.52.3022: tcp 0 15:27:20.335757 IP 184.108.40.206.40800 > 220.127.116.11.3022: tcp 0
Are you testing from inside or outside of your LAN ?
Please test outside/external, for example and mostly the easiest way with your Smartphone.
This test was from outside.
18.104.22.168 is outside and 22.214.171.124 ist the ip of the pfsense. 10.1.11.175 is the one server inside.
Your target 10.1.11.175 is using the pfSense Box as default Gateway?
Are you in manual NAT mode?
So the 141 address is your wan, and your trying to forward to your inside box... So traffic is getting to your wan which is step 1 in figuring out where your problem. So now sniff on the lan side of pfsense to validate pfsense is sending on to your 10.x address..
All of the info needed to figure out where your problem is documented in the troubleshooting guide.
BTW your hitting 3024 which is not what you stated as your forwards 3022 is what you state is your forward to ssh
Sorry but not going to follow some link to some nextcloud of a new poster with a total of 3 posts in this thread ;) Attach your screenshots if you want people to see them.
Thanks johnpoz... I've edited both answers. Perhaps I should take a break ;-)
The inside machine is using another gateway (octogate firewall) to go outside. The configuration in the octogate firewall allows all outgoing traffic from this inside machine.
I tried to set all settings as described in Common Problems
I will try sniff the lan side...
...set the pfSense Box to default Gateway and give it a shot.
good idea! It will try it when I'm back at school (there is the pfsense an octogate)...
So now sniff on the lan side of pfsense to validate pfsense is sending on to your 10.x address..
How does this works? I thought the "Packet Capture" capture also the traffic from pfsense to inside?
The inside machine is using another gateway (octogate firewall) to go outside.
Well how do you think that would work ever??
Why would the client ever accept that return traffic? I sent traffic to 126.96.36.199 and get answer back from 188.8.131.52 - doesn't work!!!
Packet capture is on the interface you select.
ok - I've tested the pfsense as default gateway and everything works fine. So far so good.
But I can't change the default gateway of our window server from the octogate firewall to the pfsense firewall. What can I do?
I don't understand why this depends on the default gateway.
Why doesn't the internal server answer directly to the pfsense when the request comes from the pfsense? What do I have to do? I need several changes in the octogate, don't I?
Thanks for your help!
There are 2 solutions you can do here, if the server your wanting to talk to uses a different default gateway other than pfsense.
Setup a route on the server telling it to get back to the tunnel network your using to use pfsense as the gateway for that dest network.
Setup source nat on your vpn connection so that clients talking to this server will be natted to the pfsense IP address in this network. So the server doesn't have to use any gateway to talk back, since the server has an interface on this network.
Thanks! I've solved the problem. I added a outbound rule (Firewall > NAT > Outbound tab) for the LAN interface:
- source of ANY
- destination of 10.1.11.175/32
- translation = Interface address
Now, the next problem appears. More about it in an other thread...
take it that 100 is really a 10 and that just a typo ;)
Glad you got it sorted