Special config for port frwds via CARP?
-
Are there any extra configuration steps when configuring port forwarding via a WAN CARP? I have the port forwarding mappings configured under NAT and the corresponding firewall rules (which pfSense created automatically), but all my port forwards get stopped by the Default Deny Rule. Is there anything not specifically listed on the pfSense documentation site that's needed when port forwarding through CARP?
BTW, I was also having trouble with 1:1 NAT until I changed the VIPs from Other to CARP. I also tried rebooting the Cisco router connecting the pfSense cluster to our ISP's fiber optic connection and rebooting the switch for our internal network, but that didn't help the port forwarding problem.
-
The only special thing you need to do is choose the CARP VIP as the 'external address' for the port forward. And, as always, ensure that your firewall rules specify the internal ip:port of the forward as the destination, not the CARP IP or WAN IP.
-
That's exactly how I have them configured, but the Default Deny rule stops any port forward attempts. I don't have any VIPs for the two external IPs that make up my WAN CARP. Should I create VIPs for them, too, or any firewall rules for those addresses?
-
You shouldn't need anything else.
If your packets are being blocked by the default deny rule, then your firewall rule is not matching them.
Can you post a screen shot of your WAN rules, port forward config, and some blocked packets from the firewall log?
-
The alias "EdXP" is assigned to a single address on our internal network. The external IP I blacked out is the external IP of the WAN CARP. The pfSense box was downed after my last attempt to get it working and it looks like the log file from that night is gone. I am certain that the log entry showed an attempt from some other external IP to the correct internal IP and port and the reason given for the packets' not getting through was the Default Deny rule. Don't know whether it matters, but 1:1 NAT is working fine after I changed the external VIPs to CARP from Other (that's why I was asking about the IPs of the two external WAN cards in the pfSense cluster).
-
Without a firewall log entry to check that against, it won't tell us anything, unfortunately.
It looks right, but just as a test, what happens if you use an IP address instead of an alias?
-
I can't try that till late tonight. I'm replacing an existing firewall/router and have only a small window in the wee hours to switch over to the pfSense cluster and try it out. And I'll be sure to save the logs this time. But, like I wrote earlier, I am certain about the Default Deny rule stopping the forwarded packets. I was watching the logs while somebody outside our network was trying to connect via a forwarded port that works with our current firewall. The destination IP was the local IP and the port was correct. When I clicked the red X the reason given was "Default deny rule".
Now that I think about it, there were a lot of entries in the log for ICMP packets' being blocked by the default deny rule as well. The source was the real external IP of the other pfSense box in the cluster and the destinations were local addresses in the 1:1 NAT mappings and the WAN CARP external IP.
If using an IP address instead of an alias works, do you think switching all Host aliases to Network aliases with a 32-bit network mask would work?
Thanks very much for your help.
-
Now that I think about it, there were a lot of entries in the log for ICMP packets' being blocked by the default deny rule as well. The source was the real external IP of the other pfSense box in the cluster and the destinations were local addresses in the 1:1 NAT mappings and the WAN CARP external IP.
Did you check both boxes to make sure that their CARP status showed properly (e.g. 'master' on the primary and 'backup' on the secondary)? Seems like an odd thing to see.
If using an IP address instead of an alias works, do you think switching all Host aliases to Network aliases with a 32-bit network mask would work?
Probably not, but I'm not sure. It's worth a try, but I'm curious more about a problem with aliases in general in that box, not just a certain type.
-
Did you check both boxes to make sure that their CARP status showed properly (e.g. 'master' on the primary and 'backup' on the secondary)? Seems like an odd thing to see.
Not exactly when I was testing port forwarding, but the times I did check it (before and after testing) each machine showed the proper status.
It's worth a try, but I'm curious more about a problem with aliases in general in that box, not just a certain type.
Do you mean a problem like a known "gotcha" with aliases? or problem like I really fouled things up while creating aliases? This may or may not be relevant, but the first WAN firewall rule allows DNS queries to the alias for the external WAN CARP IP and that rule works (it wasn't showing up in the logs as blocked and TinyDNS's log showed queries being answered).
At any rate, I'll take notes tonight and keep up with the log files. Thanks again.
-
I think I've figured it out. The problem was with an alias I'd created. I didn't know that VNC is a built-in alias for port 5900, so I created one with the same name and port number. The last time I switched over to the pfSense cluster, the VNC connection port forwards were the first and only things I tried; when those didn't work I assumed that no port forwards worked. So today I selected VNC from the drop-down instead of typing the alias I created and packets were allowed through (to the firewall at least; I was testing this with a notebook on a fake WAN) where before they were being dropped by the Default Deny rule. All apologies for my carelessness.
