@viragomann Ah crap, yes I remember this now. Thanks for the reminder, working now.

-Adam

yup split dns
https://docs.netgate.com/pfsense/en/latest/nat/accessing-port-forwards-from-local-networks.html#method-2-split-dns

@Derelict said in NAT Port Forwarding and associated rule(s) help:

Most people make an Alias containing the list of source networks they wish to allow and use that as the source of the port forward.

@N8LBV And to expand on this concept a little bit, you can also create an alias of all the ports, or port ranges, that you want to allow, then use that alias in a NAT rule or firewall rule.

Jeff

It works. Thanks very much @johnpoz !

@trevorstuart
Not exactly. If you bridge WAN and LAN, both interfaces are in the same L2 network. So pfSense is neither a router nor a gateway anymore, the gateway would be the modem. WAN and LAN devices are in the same subnet and you have to do any forwarding even to devices behind pfSense on the modem. But you are still able to filter the traffic on pfSense.

Can't you deactivate the DHCP server on the modem and let pfSense do that job in WAN subnet? The DHCP server on pfSense can push the route for the LAN subnet to the WAN devices. So you don't need to set it manually.

@vpnguy said in Can't get LAN traffic to connect through WAN:

@viragomann Thanks a lot! You were very helpful.

What would you recommend is best way to troubleshoot making sure that there is no cross traffic between OPT1/VPN subnet and LAN subnet?

You can setup an explicit BLOCK or DENY rule on the OPT1/VPN subnet from getting into the LAN subnet. Do it like this:

Action: Block or Reject
Interface: OPT1/VPN
Address Family: IPv4+IPV6 (or IPv4 if you've turned off IPv6)
Protocol: Any
Source: OPT1/VPN Net
Destination: LAN Net

Give it a good description and save the new firewall rule. Make sure it's at the TOP of your list of rules, and it should work fine. Hope that helps!

Jeff

You cannot see that in a packet capture, at least not on the internal interface.
You can do a capture on WAN while updating the system time on the client. If the packets do not appear there the NAT will work.

And then hey when want to go back to the kitchen - back to the front door ;)

In the big picture prob doesn't matter all that much, unless your moving a lot of traffic. But it sure is not the "optimal" sort of setup..

Why would you want to do that?

I follow the instructions, remove default gateway in firewall rules, to default.

I can see the firewall log it says allow (green check), however, still does not connect.

Any other idea?

Because I still can't do event ping between LAN and DMZ.

BTW: If I set "default" gateway in System/Routing, no LAN client can browse internet. Maybe something else is missing?

Note: I'm going to make a new post instead of editing my existing one. I did not see an error message when I submit my changes, so I'm going to make a new post documenting my experience with NAT.

Okay, so I'm going to document my experience with NAT in pfSense.

Let's change the destination to 10.249.1.0/24.

Rule 1:
Interface: WAN
Source: any
Destination: 10.249.1.0/24
Translation Address: 10.249.0.0/16

Pinging 10.249.1.100 works and pinging 10.249.2.100 does not work.

So, changing the destination to 10.249.2.0/24 makes pinging 2.100 working, but 1.100 does not.

I'm going to reset the destination to 10.249.0.0/24 and modify the translation address to 10.249.0.0/24. I'm going to give it a try:

Rule 1:
Interface: WAN
Source: any
Destination: 10.249.0.0/16
Translation Address: 10.249.0.0/24

Setting translation address to 10.249.0.0/24 works fine when pinging .1.100 and .2.100.

What happens if I set the translation address to just interface address?

Setting the first rule to WAN address won't work because pfSense does not seem to reach back to .0.101 when I try to ping .1.100 and .2.100.

So it makes sense to think that pfSense will translate the packets back to the originating host's IP address and not the interface address (172.24.9.2). I don't know how that works, but hey, it works. Maybe somebody could explain why using the local /24 LAN subnet works.

That's straight forward. I had made such forwardings several times.

Ensure that Pf2 is the default gateway for the server and that a firewall rule on the specified OpenVPN interface is allowing the access and that it matches. Also on Pf1 WAN you need a rule allowing the traffic, of course.

@Ilya-V said in Trafic Redirect:

added a permissive rule for everything

You have to ensure that there is no rule on the OpenVPN tab which matches the traffic. OpenVPN is an interface group including all OpenVPN instances you're running and it doesn't work on interface groups! That's why I wrote "move the rule from OpenVPN...".

Some may slip away into obscurity, but I owe a reply.... lol

Just reading this a couple of minutes ago. When I read your last suggestion about anyone else using IP on segment, I sort of cringed. I had looked at the Diag/arp and saw FW mac, but hadnt looked at EdgeRouter due to ssh issue last night. When I logged into router I saw that the network has been sliced to a /27, not /26 as I had thought. Added a usable IP from IPSUB and off and going.
Thank you

I set up the DMZplus mode to my laptop. If I SFTP to the laptop, the speeds are atrocious, just like to the netgate device. It must be the modem.

Nat overload is a classic cisco term
Also called pat (port address translation) or plain nat as we know it in home appliances.

Is the WAN gateway shown as online on the dashboard?

Are you able to ping 8.8.8.8 by the IP address from pfSense to rule out a DNS issue?

If the issue is on the VMWare setup the Virtualization section of this forum might be a better place to ask.

First, thanks for the reads and comments. It seems that, upon seeing my WAN Address as 172 and not my IP that something was fishy with the modem. Either ATT or a power cycle reset the modem to block traffic and not pass it all to PFSense. I changed that setting, and we are back in action.

I'm sorry to have wasted your time on this, as I assumed my settings on the modem were unchanged.