NATting with Hybrid Outbound Not Working on a new Mapping entry
-
I have a pfSense+ with paid TAC Lite support and was told that this question is outside the scope of "TAC Lite" support:
pfSense+ v23.09.01
We have several Public IP Addresses.
I have been using Hybrid Outbound NAT without any problem.
I have several other entries that currently do not have problems, and are working just fine.I have noticed that new entries seem to be forcing a CIDR value (/32) for the Translated Public IP address, where others previously did not have this...
The newest entry will not work. It still sends traffic out originating from the outbound interface's default public IP address.
I see that there is a message thread stating that it "Sometimes" does not work, but it seems that this situation is different, as it does not work just for my most recently added Mapping.
Can someone advise?
-
@KB8DOA said in NATting with Hybrid Outbound Not Working on a new Mapping entry:
The newest entry will not work.
May we get a look at it?
-
@viragomann
It is the first mapping that is not working:
Traffic appears as coming from 215.194 to the Internet, instead of the expected 215.195
Also - here is the Rules for the 172.17.18 subnet:
And here is the state table for 172.17.18.18:
Where you can see the last line shows 172.17.18.18 going out as 215.194
-
@KB8DOA said in NATting with Hybrid Outbound Not Working on a new Mapping entry:
nstead of the expected 215.195
Is this IP assigned to the WAN_200 interface?
If it is you should be able to select it from the drop-town in the outbound NAT rule, so there would be no need to use "network" and enter the IP in CIDR notation.Is here any certain reason for having static ports enabled in all rules?
-
Yes the Public IP is assigned to that interface.
I changed the Mappings to use the drop-down entry instead.
Still did not work.
Static Ports are in use because of VoIP Calls.
If I do not use Static Ports, the calls end up with one-way audio.What did fix the Mapping issue is:
I rebooted the pfSense this morning - then it started working as expected.I have seen issues with KEA DHCP resolved with reboots.
But now also this...I should not have to be rebooting pfSense in production environments to make things work.
I am quite disappointed with what I have been seeing with pfSense recently.