Default Gateway
-
@Tiny-0 default defines a function in this case.
"A selection made usually automatically or without active consideration due to lack of a viable alternative.."
If you have no alternative, ie a different/better route that says go here.. Then default route is what is used.. That is a function ;)
Sorry that the way to set policy routing is too much work for you.. But doing something with like a source network route in the routing table I do not believe works for pfsense, because I don't believe it uses multiple routing tables..
If setting the option to use a specific gateway is too many clicks for you.. Create a rule, and then copy the rule and just edit the other aspects of the rule.. The copy will maintain the policy route setting.
-
@viragomann said in Default Gateway:
This does S-NAT, as it's name implies. Nothing else.
It translates the source addresses in outgoing packets to any other, you can state. But it does no routing at all.Coming from Sophos UTM, i've been trying to wrap my head around how pfsense nat differs in terminolgy.
Under the NAT section in UTM, they have 2 tabs - masquerading and NAT.
Network - refers to the local lan (ie 192.168.1.0/24)
Interface - refers to the wan interface (public internet facing interface)
Use address - is the assigned public ip (via dhcp from isp).The nat tab allows defining various NAT's
The DNAT variant changes the "change the source to:" to "change the destination to".
From what I can gather, in pfsense, the closest thing to the masquerading equivalent is the default outbound nat rules. While the "NAT" tab equivalent would be outbound nat rules for SNAT or port forwarding for DNAT. Is this an accurate understanding?
With respect to multiple gateways configured (ie wan and wireguard), any settings in the outbound NAT will not affect which gateway is used to egress that traffic. That is, nat settings (as mentioned in the quote), only affect addresses. Which interface this traffic leaves on (from) is set entirely in the firewall rule of the original source interface said traffic came into the firewall on (LAN for example). Is this correct?
Thank you.
-
@GPz1100 said in Default Gateway:
From what I can gather, in pfsense, the closest thing to the masquerading equivalent is the default outbound nat rules. While the "NAT" tab equivalent would be outbound nat rules for SNAT or port forwarding for DNAT. Is this an accurate understanding?
Yes.
Under the NAT section in UTM, they have 2 tabs - masquerading and NAT.
NAT = Port Forwarding (= DNAT)
masquerading = Outbound NAT (= SNAT)DNAT translates the Destination address in packets, while SNAT translates the Source address.
With respect to multiple gateways configured (ie wan and wireguard), any settings in the outbound NAT will not affect which gateway is used to egress that traffic. That is, nat settings (as mentioned in the quote), only affect addresses. Which interface this traffic leaves on (from) is set entirely in the firewall rule of the original source interface said traffic came into the firewall on (LAN for example). Is this correct?
Which interface to be used for outbound traffic is a thing of routing.
Traffic which is entering pfSense on any interface can be policy routed by firewall rules. If you do not state a gateway in the rule the traffic follows the default route or static routes if you have added any (System > Routing). -
Regrets that I was not sufficiently informed of pfSense detail to assist preceeding contributors.
Meanwhile I have been relatively happy to reduce need of extended (gateway) rules by defining System>Routing>Default as Wireguard.
However, there is something like a race situation since pfSense startup leaves the Wireguard default offline. It is necessary to set Default Gateway as WAN and preform "reroot" start, then reset Gateways as wanted. Is there a remedy (perhaps posted elsewhere as I haven't looked)?
My lack of information extends to another "crash report", with Wireguard apparently incorrectly configured, which co-exists with the above problem (which is not as big a problem with infrequent starts as was finding a remedy in the first place)!
-
@Tiny-0
A gateway failover group should switch the gateway automatically according to the stated priority.Create a gateway group (System > Routing > Gateway groups), set the WAN as Tier 2 and the Wireguard as Tier 1.
Then go to System > Routing > Gateways and select the gateway group at default gateway.
Ensure that gateway monitoring is enabled for both and a convincing IP is used.Thenceforth if WG is offline the WAN gateway is used. After the WG becomes online, this one will be used for upstream traffic by pfSense.
-
My systems on pfSense lans are all personal, with different explicit security not to be bypassed as an occasional slow but sure remedy works fine. I do not have 100 users knocking on my door (which might justify more research time!).
I had rather hoped that a crash report of config error, along with the constant Wireguard (as default gateway) startup (and occasional other) offline status might suggest to someone a remedy that I can’t so far find (i.e. my effort with crash report would exceed my trouble fixing it). My remedy ALWAYS puts Wireguard back online. Just why does it NEVER come up online when default at startup? Looks to me like a bug, pure and simple?
I have never noted Wireguard coming back online by itself (although I am not the most patient).
-
@Tiny-0
I presume, that your Wireguard connection traversals your WAN upstream connection. Hence it cannot exist before for plausible reasons.
So WAN has to be the default gateway for a view seconds after booting up naturally. However, if it has a lower priority in the failover group and Wireguard the higher one, pfSense will switch over to the latter as soon as it is online. -
Thanks, I get the logic but don't like the implementation - a plain English error would help. However, starting with WAN as default gateway I still get crash report / bug but have not defined any resulting problem (and don't particularly want to take time until I can).
It seems to me that when various ports, including WAN, are configured before startup and basic connections established presumably early during startup, pfSense should be able to refine them without difficulty later.
-
@Tiny-0 A couple of weeks after posting here that reroot fixed Wireguard as a second gateway on v2.7.2, that remedy failed completely.
Since I had a crash rep. / prog bug reported (previously ignored) I started from "Reset to factory defaults" via console for a hoped clean start. As soon as I adjusted just WAN/LAN interfaces via console my GUI again declared "crash rep. or prog bug"!
This really is too much after years using fairly basic pfSense functions. If there is some hardware problem why not say so as I've changed near nothing from defaults otherwise?
m/b: MSI B450M Pro-VDH
cpu: Ryzen 5 2400G
net: Intel I350T4 (LAN etal) +m/b WAN working ok. -
@Tiny-0 GUI statement of "Crash Report or Programming bug" was a myth removed, along with potential hardware incompatibility, by reinstall from USB and restore of the same config! This booted without "crash or bug" message.
Now, v2.7.2 communicates well enough to confirm version is current but not well enough to show "Available Packages". This, by others' comments, is either a random maintenance problem or some incompatibility between package database format and BSD or pfSense versions. As I have a new unpatched install of original pfSense 2.7.2 I am rather inclined to view it as yet another Netgate bug.
So, I now have no option to add the Wireguard package that I previously had configured and running without yet more research of basics on web!
-
So now we have another random Netgate bug for which I am thnkful for a fix that I would never have found myself:
https://forum.netgate.com/topic/153708/solved-but-bug-still-present-available-packages-empty
20240824 Changed default Wan IPv6 to have DHCP6 (instead of none) and packages show! No need of IPv6 traffic.
Who could guess this would be left hanging to trap us?
