https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks

NAT Reflection works for most people, but I much prefer to use split DNS.  Put an override on your DNS so that your domains resolve to their LAN IP addresses.  Problem solved with using a hairpin connection hack.

No fancy rules needed. All you have to do is add the network they asked for in the P2. Edit the Phase 2 entry for your tunnel and right under where you have 192.168.1.0 now, there's a box for NAT options, set it to the subnet they gave you (10.100.29.0/24).

Then when your 1.x net tries to reach across the VPN, it looks like it comes from 10.100.29.x, and when the far side needs to reach your 1.x net, they talk to 10.100.29.x instead and the NAT will get it there.

Hi,

Did you create a phase 2 for Othernetwork to 12.9?

You would craft a P2 for the IPSec tunnel to send your traffic from the local source to that remote IP address over IPsec, and then the far side firewall would perform outbound NAT there.

You don't use aliases, you use Virtual IPs.

https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses

Once you have assigned your 5 IPs to your WAN, the net step is to create NAT rules that direct traffic from your public IP/port to LAN IP/port.

https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense

https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

what device is it that does not allow you to set a gateway?  Doing a source nat is a work around, not the correct solution to the problem.  Your device is not meant to be used outside of its own layer 2 network for what reason?  What is the device?  Some wifi router your trying to use as AP?  If it supports putting 3rd party firmware on it like openwrt or dd-wrt, etc. this would allow you to set a gateway.

I figured its some corruption in the firmware - I used another machine and it worked great. Thanks for your help. I will close this case now

Im glad too :) I will take a look into the split dns also. It may be a bit more work since I dont use dns for all of my services but I can of course add host overrides to each one.

thanks for the tip
I will try it with squid to see

yeah I think they only allow outgoing port 22 on my pc here, so I requested to open the other ports
we'll see

thanks anyways, If it is not solved that way, I'll come back :-)

It will show that in the log, but the state table should show it getting NAT applied.

Still, a NAT rule like that with a source of any is an awful idea. Match the traffic more precisely (source = your WAN IP address, destination = any, port 69)

Though TFTP is a mess of a protocol, it'll still probably need some other nonsense to make it work.

Hi CMB,

Thanks for the reply.

I have already tried the NAT without the rule, with no success.
Perhaps something with the ProxyARP IP address.

It does seem to work OK directly on the WAN ip address

Hi cmb,

Thank you for your reply.

My ISP had provided me with the WAN IP and /28 which is supposed to be routed as you said …. I'll follow up with them.

Regards.

huh??  If you want pfsense wan to have internet it needs to point at the gateway that gives it internet.

Brilliant!

I removed the 2 NAT rules I added earlier, and added a new rule for the WAN interface, with the source as the /26 network, and selected No NAT.  I switched it over to hybrid, and made sure the server was still online and that NAT was disabled for it (using a cURL command to send a request to a public IP return service).  My backup LAN device still wasn't able to get out, but I looked down at the automatic rules and noticed that even though they included the LAN network in the source (all interface networks, actually), they were set for only the WAN interface.  I created a new rule on the LAN interface with the LAN network as the source, and selected Interface Address for the translation address.  Now the LAN device can get out on the main IP and the public routed subnet works fine also.

Thanks, this was helpful.

Packet filtering and address rewriting are two separate processes in PF. Regardless of the address rewrite method you have to allow access with packet filter rules and the filter rules will be identical in both 1:1 and port forward NAT cases assuming that the goals are the same in both cases when it comes to access.

Quick note-  If you really are using 172.0.0.1 as your LAN you shouldn't be-  Unless your using AT&T uverse and have public IP addresses on your stuff.

Private space starts at 172.16.0.0

Lookup Result for 172.0.0.1

| IP Address: | 172.0.0.1 |
| Host of this IP: | 172-0-0-1.lightspeed.brhmal.sbcglobal.net |
| Organization: | AT&T U-verse |
| ISP/Hosting: | AT&T U-verse |