Firewall Rules-Port forwarding broken
-
OK…if someone wants to point me to logs that are needed I will post.
1. When entering ports in firewall rules, it is not possible to set "other" as the external port UNLESS "other" is internal and identical. If you set say port 22222 as external and 22 as internal, the scripts invert the it to 22 external 22222 internal. I can find no way around this. It is beyond annoying and makes it so the system cannot be deployed in a production environment.
2. There is something quite wrong with the rules set. For instance, I successful set port 64389 ext to port 64389 internal. Checking from CLI I see from pfctl -sr that the rule is loaded:
pass in quick on fxp0 reply-to (fxp0 x.x.x.x) inet proto tcp from any to 192.168.64.5 port = 64389 flags S/SA keep state label "USER_RULE: RDP Ringil"
However, the logs show that attempts made to connect are being blocked. (I can post a log tomorrow from work).
I do have some rules that were set up before the rc0 upgrade, and they appear to be functional at the moment.
Any help in tracking these issues down would be welcome.
I have installed pfSense-Full-Update-2.1-RC0-amd64-20130612-1823.tgz.
System:
CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1676.70-MHz K8-class CPU)
real memory = 4294967296 (4096 MB)
avail memory = 4083286016 (3894 MB)
re0: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" pcie="" gigabit="" ethernet="">port 0x2000-0x20ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci1 -- Internal
fxp0: <intel 100="" 82550="" pro="" ethernet="">port 0x1000-0x103f mem 0xf0120000-0xf0120fff,0xf0100000-0xf011ffff irq 21 at device 0.0 on pci5 -- external
[2.1-RC0]diskinfo -v /dev/ad6
/dev/ad6
512 # sectorsize
32044482560 # mediasize in bytes (29G)
62586880 # mediasize in sectors
0 # stripesize
0 # stripeoffset
62090 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
DC0108460D5E50093 # Disk ident.</intel></realtek> -
Can't replicate #1. What are the exact steps, and what browser are you using?
#2, that rule is only part of the equation, the rdr would have to match before it would hit that rule. Guessing your rdr doesn't match.
-
Can't imagine what the browser would have to do with it. Firefox 22.
rdr? Please clarify. I am setting up rules the same way I have always done. Where or why this "rdr" is set or has suddenly become important is not obvious, if it is indeed the issue.
Logs show the block is due to:
The rule that triggered this action is: @3 block drop in log inet all label "Default deny rule IPv4"
Why this rule should kick in for NEW port forwards, but old existing rules are unaffected is a mystery to me.
-
Issue resolved. for 1 &2. Thanks for the help, you pointed me in the right direction there.