Gltich with NAT ports (ext. diff from int)
-
Tried this a couple of times with the beta 3 embedded….by default when I create a nat rule where the external port is different than the internal port the firewall rule is for the internal port range and not the external port range. I can manually go into the firewall rules and adjust the port range there and it fixes the problem but just a little glitch i noticed.
-
Tried this a couple of times with the beta 3 embedded….by default when I create a nat rule where the external port is different than the internal port the firewall rule is for the internal port range and not the external port range. I can manually go into the firewall rules and adjust the port range there and it fixes the problem but just a little glitch i noticed.
Filter policy occurs after NAT. The filter policy must match what the packet looks like after NAT or it'll get blocked. This doesn't sound like a bug to me?
–Bill
-
example: I have to services running on port 80 on the local machines behind the firewall, on the outside you will hit port 80 and 81….80 is setup straight through but when second one is defined it goes as follows.
Firewall--> NAT
Add
(values are left default unless otherwised noted)
Ext port range: 81
Nat IP: 192.168.1.21
Local port range: 80
Auto-Add Firewall Rule
Save
ApplyFirewall -> Rules
Rule defined shows source and port as any then dest. ip as 192.168.1.21 and port as 80When attempting to hit port 80 or 81 from the outside fails.
Firewall -> Rules
Change the Rules for 192.168.1.21
Change the Destination port to 81
ApplyTry again from the outside and 80 and 81 work.
....
Am I missing something(....might be a bit spacy, final projects and no sleep:P) -
As on original OpenBSD, Bill's right about that. A rule is matched against the filter, after it has been processed by the rdr/nat-part. So in your case, the rule (correctly) states port 80 on the internal ip. If that is not working (will try when I'm home), then sth. with pf on freebsd would sure be strange, but at the moment I couldn't remeber problems with that part of filtering/nat
Greets
Grey -
As on original OpenBSD, Bill's right about that. A rule is matched against the filter, after it has been processed by the rdr/nat-part. So in your case, the rule (correctly) states port 80 on the internal ip. If that is not working (will try when I'm home), then sth. with pf on freebsd would sure be strange, but at the moment I couldn't remeber problems with that part of filtering/nat
Greets
GreyThe problem I was having is that when the rules were created in the ruleset it listed both internal IP's with port 80 assigned instead of 80 and 81.
-
Thats absolutely right. RDR/NAT rules are proceeded first, afterwards filter rules are evaluated. So when the packet arrives at filter level, it already has changed from "external IP port 81" to "internal IP#2 port 80", so the filter has to allow a packet that has an internal "to" address and the already modified port 80.
Hope that wasn't that bad an english explanation, it's late and been a stressy day :)
-
The problem is that when it creates them that way they cancel out each other and the ports are not accessible from the outside.
-
The problem is that when it creates them that way they cancel out each other and the ports are not accessible from the outside.
If you see a problem how about offering a patch?
