Load balance Nat port forward not working
-
Patience and a good attitude go a long way toward getting help from a volunteer forum. Lots of people use it in high-end environments with much success.
My answer earlier was a bit vague, but I was referring to the port forward portion. A side effect of skimming, which is my fault. With port forwards you need IP bypass not MAC bypass. MAC bypass works like a portal auth, it requires a periodic web access to renew the 'session' - an IP bypass does not suffer from this.
Captive Portal and Multi-WAN is a bit trickier but I haven't tried it, as you said it's likely only possible on 2.0 (which many people are also using in production… with caution)
Why not just let the RV042 handle the multi-wan bit and let pfSense do the portal? You should be able to setup port forwards/1:1 nat in the RV042 to pass your forwarded ports back to pfSense and then inside. Or disable NAT on pfSense if the RV042 can handle multiple internal subnets with static routes. Or just use 2.0 (though captive portal is broken in current snapshots a fix is going in as I type this).
Tens of thousands of people use pfSense, everything from home users, businesses of all sizes, enterprise class, you name it. Commercial support is available for people who need immediate professional consultation (or who just want to donate to the project and get something for their money) and we have no shortage of customers.
Just because it didn't do exactly what you wanted in one specific scenario in a -release (and the beta can) is no reason to talk trash about the project as a whole for the needs of everyone else.
-
yes, I am dumping, and I apologise, but that's because I'm rapidly going nowhere and feeling frustrated.
I tried your suggestion with no luck. Does the router need a reboot every time I make a change? That means I have to kick everyone off it, and that's going to land me in hot water pretty quick. I just tried a reset but it made no difference.
Here is the settings I changed. What I don't understand is why one works and the other doesn't. If I'm going to 192.168.1.60 via https port 8080 it works. If I go to 192.168.1.100 https port 9100 it doesn't? Setups are the same, I can access from the lan np, the rules should be set to allow access. I ping it and get a reply. I know it's working because there's a bunch of clients going thru it, but I can't get to it? WTF?????
-
Settings should take effect right away in most cases, especially when it comes to port forwards.
I noticed in your port forward definitions the 9100 is set for tcp/udp. Have you tried setting that to just tcp?
-
tried tcp and tcp/udp, no difference.
-
Have you gone over all of the usual troubleshooting steps?
http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
Usually if one works and the other doesn't, and the setup is identical, it ends up being something on that machine (not using pfSense as its gateway, local software firewall, etc)
Some packet captures on the WAN and LAN sides would help narrow it down, you could see how the traffic is (or isn't) flowing to that server.
-
Just set Wan1 to turn on logs. Sure enough it's blocking. It says:
@62 block drop in log quick all label "Default block all just to be sure."
turned on logs for the porting that worked. It said:
@49 pass in log quick on vr1 inet proto tcp from any to 192.168.1.60 port = 8080 flags S/SA keep state label "USER_RULE: NAT cannery Router"
Cative portal ip exclusions look like:

 -
more detailed log info
bad response:
pf: 3. 008448 rule 62/0(match): block in on vr1: (tos 0x0, ttl 124, id 279, offset 0, flags [DF], proto TCP (6), length 48) xxx.xxx.53.7.2039 > xxx.xxx.1.79.9100: tcp 16 [bad hdr length 12 - too short, < 20]Good response:
pf: 068366 rule 49/0(match): pass in on vr1: (tos 0x0, ttl 124, id 24514, offset 0, flags [DF], proto TCP (6), length 48) xxx.xxx.53.7.2071 > 192.168.1.60.8080: tcp 16 [bad hdr length 12 - too short, < 20]It seems that the bad one has the extenal IP adderss, the good one has the internal IP address. Is that because it has passed thru?
Could it be because 192.168.1.60 gets dhcp and 192.168.1.100 doesn't? That would be weird.
-
I have been through the troubleshooting a few times. I have tried a bunch of different settings.
I dunno.
-
I finally figured out everything and it works! Yay!
The key was that I had to set up NAT port forwards, which sets up the rules, AND I had to set up captive portal allowed IP addresses. I had thought I didn't need the NAT forwards because I had the Captive portal allowed IP addresses and the rules set up. So MAC=bad, IP=good when setting up Captive portal NAT forwards.
So, I need to apologize for dumping on the pfsense, and thanks to jimp. I was getting really frustrated at not getting anywhere after spending about 3 days trying to get the port forwards working. What was screwing me up was that some of the forwards worked, and some didn't. The first 3 rules worked fine with Pass Thru MAC, but the other 3-4 rules didn't work, even though they were set up the same. I guess that's just one of those oddities with the system. Once you know these things it starts to make sense.
I don't know if anyone can update the tutorials, but that sort of key info makes life much, much easier.
-
Unfortunately both of the howtos you linked are contributed and aren't on our Wiki or I could update them rather easily.
I did add a note here:
http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting#Common_ProblemsAbout needing an IP bypass for a port forward to a server behind a captive portal.