Outbound portforward NAT response back not working on 2.5.2
-
I have 2 WAN connections with there individual gateway but i have disabled the default gateway in routing
Instead i have set the gateway in the firewall like this
And this is my port forwarding rule set in NAT
Now the issue is if i am even trying to reach the port 2337 from outside it says the port is closed, so i did some packet capture on my VLAN and found that my server is responding back to the request as you can see here ( 10.10.10.53:2337 is my local server which i am trying to access from outside network )
But i found out that my PI_Gateway is not responding back the response as you can see below in packet capture ( 192.168.7.110:2337 is my PI_WAN ip address )
All this gets fixed in i choose a default gateway in Routing tab but i dont to choose a default gateway in routing i want to do it manually, what am i missing or doing wrong here ?
i am using 2.5.2 version
-
@viiniit said in Outbound portforward NAT response back not working on 2.5.2:
I have 2 WAN connections with there individual gateway but i have disabled the default gateway in routing
I think, pfSense will need it for its own upstream traffic routing.
Instead i have set the gateway in the firewall like this
Consider that these rules only affects upstream traffic, but not incoming packets.
However, this should not cause that responds don't work.
Ensure that the associated firewall rule is really applied to the incoming traffic.
Do you have any floating rules?
Or interface group rules? -
@viragomann said in Outbound portforward NAT response back not working on 2.5.2:
Ensure that the associated firewall rule is really applied to the incoming traffic.
Here is the associated firewall rule:
Do you have any floating rules?
Or interface group rules?No for both floating rules and interface group rules
-
@viiniit
On addition possible reason, I can think of:
The PI gateway IP must be set in the PI interface settings, is it? -
@viragomann said in Outbound portforward NAT response back not working on 2.5.2:
The PI gateway IP must be set in the PI interface settings, is it?
yes in the PI interface i have set gateway to 192.168.7.1
-
@viiniit
Hmm, it should work with that.For investigation, please set the WAN gateway as default and try the access again.
If you've done all settings properly it should work as well then. -
@viragomann said in Outbound portforward NAT response back not working on 2.5.2:
For investigation, please set the WAN gateway as default and try the access again.
when i set Default Gateway in Routing it works!
but i didnt want to use default routing so is there no other way to make this work ?
-
@viiniit said in Outbound portforward NAT response back not working on 2.5.2:
when i set Default Gateway in Routing it works!
So no matter, which one you select?
but i didnt want to use default routing so is there no other way to make this work ?
As mentioned, I don't understand your intention here. The default gateway will be necessary for pfSense to access internet resources, I assume.
-
@viragomann said in Outbound portforward NAT response back not working on 2.5.2:
So no matter, which one you select?
yes no matter which one i choose
-
@viiniit
Okay, this behavior is new to me and it's a bug in my view, which the Netgate guys should know about.Anyway, I don't see any reason for not setting a gateway as default, since the routing works properly with that.
@jimp
Obviously the reply-to doesn't work in CE 2.5.2 if the default gateway is set to "none".
Seems all other settings are correct like the gateway IP in the interface settings, no interface group rules, no floating rules.
And as the TO stated, it works properly if he selects any gateway as default, no matter which.
So I think this is a misbehavior, which should be corrected. -
There may be a bug there but running without a default gateway is a bad idea and isn't doing what you think it's doing. Setting a gateway in rules only affects traffic for hosts on the local networks matching those rules, not the firewall itself. And doing that in outbound floating rules doesn't actually help move traffic out different interfaces in most cases.
The firewall itself always needs to have a default gateway. If it doesn't, services on the firewall can't properly get out to check for updates, install packages, DNS may fail, VPNs can't establish, etc. Some of that can be worked around with static routes for specific remote hosts but still, it's not ideal.
The "none" setting for default gateway is primarily intended for situations where the default is managed by BGP or OSPF, NOT for policy routing.
tl;dr; There may be a quirk there but you're running an unsupported configuration so not something that would be a priority to investigate.
