Nat & ssh problem
-
In a couple of places, you have rules saying {tcp udp} for a tcp service - get rid of the udp it just confuses things. Also, your post refers to 192.168.0.10, but the rules are referencing 192.168.1.2 - is this an error, or did you change the IPs and not post that? Anyway, this all looks correct - the only thing I can see as a possible issue (that might explain the inbound SSH request not getting through and not being blocked by PF) is snort. I have stopped using snort myself, due to false positives that resulted in good hosts being blacklisted. Could that be it?
-
Hi danswartz
Sorry I did not mean to confuse you, it was not the logfile of the threat starter but I have
exactly the same problem, I cannot access 192.168.1.2 in the LAN segment and found no lasting
solution so far.
Well I am not using snort but I will check the restThx thafener
-
Oh, sigh. This is confusing. I hadn't noticed I was dealing with two different posters :( So, thafener, when you try to connect to ssh from outside, is it blocked by the default rule or it just goes nowhere?
-
Sorry for all that mess danswartz I do not think that the ssh packages are blocked by the default rule as I can see
them pass in the firewall log but I cannot connect to the ssh host which is possible of course from the LAN side.
It is really confusing that I already "solved" this by making the SSH NAT rule the first one and it has been working
fine for a while but unfortunately the problem occured again.
I have a second PFsense system running in a different location and here it is the same with natting FTP.
I cannot access both boxes from here but I'' get back to this with a little more detailed log output tomorrow morning.cheers thafener
-
Ok here's some output and some screenshots of this phenomenon…first of
all a packet capture of the WAN interface on Port 22...08:09:08.760774 IP 217.71.243.136.1651 > 83.79.5.14.22: tcp 0 08:09:11.726431 IP 217.71.243.136.1651 > 83.79.5.14.22: tcp 0 08:09:17.742044 IP 217.71.243.136.1651 > 83.79.5.14.22: tcp 0Please find the screenshots of the NAT rule and the Log viewer attached
below…
-
Are you absolutely 100% positive there is no trace of the connection on LAN side? Can you run a capture there too?
-
I have made a captore in full detail but could not find packets on port 22 for host 192.168.1.2 :-\
-
Can you capture anything at all on the LAN side involving 192.168.1.2 or port 22 (e.g. two captures.)
-
I have scanned but only the capture for 192.168.1.2 produced output, sadly not for Port 22.
There is no traffic on port 22 coming through the box though it should according to the setup… -
If you try a connect (which hangs I assume, waiting for the SYN to be replied to), what shows up in the pfsense state table?
-
Yes there is something showing up in the state table, I was have used the host I am connecting from as a filter… see screenshot
-
Hmmm, this is odd. Is it possible to do a capture on the ssh server itself? I am not sure I trust the capture on the pfsense.
-
Well I used wireshark on the target host running Ubuntu and there were no SSH packages from the Pfsense box to the target host.
-
okay, thanks. boy, is that weird. question: i assume this doesn't work at all? if correct, does a reboot of the pfsense bring it back? also, do you have sshd enabled on the pfsense? if so, does disabling it "fix" this (i am not recommending that as a fix, just trying to isolate things.)
-
Yes man that's weird. Two weeks ago I had exactly the same problem and after doing everything from the book
and the troubleshooting guide I deleted all Firewall and NAT rules, made a backup without package info and reinstalled
the box from the scratch.
Then I reinstalled the packages (squid and lightsquid and the dashboard) and created the NAT rule for SSH first and
all others after and it has been working for a little more that a week.
I just noticed the high number of very similar NAT problems discussed in this Forum….really strange -
Hi @ll
Here we go again, re-installed the whole box from the scratch, re-created the Nat rule as the only
existing one and I have exactly the same problems with the same outputs as before.
Tried NATting VNC (5900) too but no joy…. would any one of you guys give 2.0 a chance or
is there any other possible solution for this ?Thx thafener
-
No clue anyone ? Might this problem be hardware-related ? I am running PF on a
Intel Atom 330 (D945GCLF2) using the onboard NIC (Realtek 8xxxx, might use much
memory but Ok…) and a 3Com 3C905C as the second NIC. Next to this the system
has 2 GByte RAM and a 160 GByte HDD.....Found nothing problematic about this hardware combination in the compatibility lists
but maybe any one of you knows more.... -
Follow up:
It seem that the whole problem happend if captive portal is enable, basically the nat just doesnt work. It looks like the captive portal doesn't undestand or just block the nat.
If anybody found a solution or has details for nat with captive portal enable, please share?
Next step, will try with a dmz. -
Spazio,
Thanks a lot for your reply… the cp is a hint, I did not consider having a look at this
side so far.
Does it mean you disabled the cp and it was working again ? Can you confirm this ?However if you make a new install from the scratch it works again as it is the same
with a lot of PFSense issues from my side.
Some functions stop working without reason or without prior configuration changes
and it is impossible to find a logical reason.
However it is good for us that the functions of PFSense allow a fast install and restore
which can be done in some 20 minutes...Thx thafener
-
yep, by disabling captive portal everything comes back to normal and nat is working again. Tried it with a new install without cp and it work.
For me the problem came from enabling captive portal.
This is a deal breaker still. There must be a way to have nat and cp enable and working at the same time