next »

[wm408]

Hello,

     I created simple pass rules to be able to access the pfSense box remotely by way of SSH and HTTPS.  However, although the rules are there, it does not seem to make a difference.  I have read repeatedly that I simply need to create a rule within the firewall rules for each service to pass to the pfSense
box on the WAN.   I am accessing the internet just fine through the pfSense box from the LAN, but unable to administrate remotely.

     FYI this is a 4G nanobsd copy of pfsense, (downloaded it a couple days ago). 

     I do recall seeing a default-deny entry at the bottom of the /tmp/*.debug file that is made to look at for troubleshooting the pf rules.  Could this have anything to do with it?  Or am I high?  Doesn't the last rule entered have priority over everything else?



    
    Suggestions?  Thoughts?   Thanks.

[kc8apf]

You seem to be specifying a specific source address that is allowed.  Are you certain that that IP is being used to make the remote requests?  Do you see the attempts show up in the firewall logs?

[wm408]

kc8apf,

     I am 100% certain that the source IP(s) are correct.  When I monitor pflog0 with tcpdump, I see nothing logged.  When I make a default deny rule manually at the top of the list, (below the RFC 1918 and reserved default ones) with logging to test, I can see it blocked.

     Its not like the SSH-server / Weggui service(s) aren't running either.. I am connected to both through the LAN.

    
      

[dotdash]

TIP- Never say you are 100% certain.
Why don't you, just for the sake of argument, change the source to * and re-test.
The two likely explanations are-
1) source address isn't matching. Turn on logging for one of the other rules (the one with the source port isn't going to do anything) and check the logs.
2) The incoming traffic is getting blocked before it gets to your firewall by the provider's equipment.

[wm408]

For the sake of argument i did "any" for the source addresses and enabled logging.  Here is the output from tcpdump:

tcpdump -vv -s 256 -e -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 256 bytes
14:13:09.887801 rule 59/0(match): block in on vr1: (tos 0x0, ttl 61, id 14122, offset 0, flags [DF], proto TCP (6), length 64) {SOURCE IP} > {DESTINATION IP}.ssh: S, cksum 0xc46e (correct), 2719442034:2719442034(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 639953150 0>

TIP- Never say you are 100% certain.
Why don't you, just for the sake of argument, change the source to * and re-test.
The two likely explanations are-
1) source address isn't matching. Turn on logging for one of the other rules (the one with the source port isn't going to do anything) and check the logs.
2) The incoming traffic is getting blocked before it gets to your firewall by the provider's equipment.

[dotdash]

Assuming the source and destination in that output match the WAN address and the remote IP,
Find what rule is matching- either list the rules with pfctl -vv or turn on logging in the gui and click the match to find the rule. You can enable logging the default deny under options. Verify the source IP is not on the bogon list (if the bogon rule is turned on for WAN)

[wm408]

I ended up running this to list the rules:

 pfctl -vv -s rules

rule #59 shows this:

@59 block drop in log quick all label "Default deny rule"

Shouldn't this rule be at the top of a PF.conf ?  (the in rule and an out default deny are pretty much at the end of the pf rules, rules 59 and 60)

I don't see an option to "pass quick" to bypass this last default-deny rule for the SSH / HTTPS rules... so shouldn't it be up top?  If so, how can I move it up there?  What file does pfSense invoke on bootup?

[jimp]

Or am I high?  Doesn't the last rule entered have priority over everything else?

You're high.

pfSense uses quick on all the rules, so it's first-match-wins. Without quick, it's last-match, but that's less intuitive to work with.

[wm408]

Lol I was actually typing a message just now talking about how all the rules are "pass in quick".  However... I still get denied by the default deny rule at the end.

Any thoughts?

[jimp]

If you're hitting the default deny, then you are not matching any of the pass rules for whatever reason.

It might help to see the firewall log output (from the GUI) for the blocked packets.

[wm408]

Yep I'm high...

     I had a typo in my rule.  Sorry!  Thanks for all the support.

[wm408]

One more thing,

     I had "synproxy state" checked under my rules and didn't realize it would affect the services / ports in this way.  But basically, whenever I had "synproxy state" checked instead of "keep state", it would skip the rule and go to default deny, and block it.  I thought synproxy worked for all TCP connections?  Who knows... guess it was always nice to see the output of pfctl whenever I loaded a new pf.conf for debugging purposes.  Is synproxy state not for HTTPS / SSH?  Enlighten me.