Port forwarding broken after 2.2 upgrade
-
Post some packet captures, firewall logs, port forward screenshots and whatever… No information to debug anything.
-
As soon as I get home. I tried rebooting remotely and to my luck it never came back online :'(
-
I just did a clean install of pfSense 2.2 on my test machine and set up port forwarding like I have on 2.1.4.
When I try to use PuTTy through 2.2, I get Network error: Connection timed out.
-
And as dok already stated - without any info you can not get any sort of help.
-
I returned home, the pfsense was able to ping google after the reboot but all of my computers could not. I reset to factory defaults and port forwarding works and all my computers could connect again.
-
Could be connected to this thread: https://forum.pfsense.org/index.php?topic=87877.0
Please try to verify, if you have the same symptoms and if issuing '/etc/rc.filter_configure_sync' at the shell-console makes the pfsense box reachable again. -
Hi,
I have too problem with port forwarding with pfsense 2.2. I install a clean version 2.2-RELEASE (i386) built on Thu Jan 22 14:04:25 CST 2015 FreeBSD 10.1-RELEASE-p4 without any custom fw rules. Everything is default, then a I create a simple rule to redirect port ssh to my debian testing machine behind pfsense..Forward rules working but take a long time after I get login prompt….
When I do this: ssh root@public_ip -p 2222 I get promt login after almost 2minutes...... In attachment I put my nat port forward rules...
-
and how does that have to do with forwarding traffic? You saying that pfsense is getting the packets and holding on to them 4 2 minutes before sending to your ssh box?
Do a sniff on the connection in diag, packet capture and see what is happening. Maybe you just have a slow ass ssh server ;) Or you have brute force protection on, etc. And its getting pounded so it delays giving you a prompt.. I know infoblox does this out of the box, you don't get prompt for 90 seconds, if you typo the password you have to wait 90 more seconds.
Look to your server for this sort of issue, if was pf not forwarding you would never get a prompt..
-
and how does that have to do with forwarding traffic? You saying that pfsense is getting the packets and holding on to them 4 2 minutes before sending to your ssh box?
Do a sniff on the connection in diag, packet capture and see what is happening. Maybe you just have a slow ass ssh server ;) Or you have brute force protection on, etc. And its getting pounded so it delays giving you a prompt.. I know infoblox does this out of the box, you don't get prompt for 90 seconds, if you typo the password you have to wait 90 more seconds.
Look to your server for this sort of issue, if was pf not forwarding you would never get a prompt..
@johnpoz - hehe I have a normal ssh box :-).. The same redirect port on pfsense 2.1 works correct, I get a login promt quick … In pfsense 2.2 default is any implement brute force protection for forward port, because no only ssh works that... Can you look on packet capture from attachment....
-
@f4f:
In pfsense 2.2 default is any implement brute force protection for forward port, because no only ssh works that…
No, there is no such thing, sorry… Things like this happen e.g. when you have a hostname with both A/AAAA DNS records but are NATing to IPv4-only accessible host behind firewall. You only get a connection after IPv6 gives up.
-
@f4f:
In pfsense 2.2 default is any implement brute force protection for forward port, because no only ssh works that…
No, there is no such thing, sorry… Things like this happen e.g. when you have a hostname with both A/AAAA DNS records but are NATing to IPv4-only accessible host behind firewall. You only get a connection after IPv6 gives up.
@doktornotor - I think found the problem.. pfsense I have run on XS 6.2 so I must disable offload…: https://forum.pfsense.org/index.php?topic=85797.15
This resolve my problem:
xe vif-param-set uuid=VIFUUID other-config:ethtool-gso="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-ufo="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-tso="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-sg="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-tx="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-rx="off"For each vif network card under virtual machine
-
You know, telling everyone you were running it virtualized in your opening post would have been helpful.
-
You know, telling everyone you were running it virtualized in your opening post would have been helpful.
Not to mention that this has nothing in common with the OP's issue apparently.
