@wolf3000
They are probably using proxy arp
That was discouraged a long time ago, for security reasons.

Why would you want that feature ?

If using DHCP the PLC should also accept the def-gw info handed out.
If using Static IP, it's just one more entry to key in.

The whole point of using a firewall is to be "In Control", and not rely on some (could even be a hostile) device, forwarding your packets based on unanswered arp requests.

/Bingo

@steveits said in 1:1 Nat routing back to firewall:

But he's trying to access the WAN IP from LAN. That seems to me like it needs reflection to work.

Yes, you're right. I didn't read correctly.

@trever
But why are you using the external IP for accessing an internal device? The suggested way is to access it using an FQDN together with internal DNS host overrides. So from within your network the FQDN is resolved to the internal IP and accessing it should be work without NAT reflection.

@steveits Thanks for your reply.

I finally figured it out. Quite obvious now that I see it.
The ATT box's programming for the "pass-through" mode requires you to enter the MAC address of the NIC that the traffic is being forwarded to. Since the router hardware had changed, of course the MAC had changed. Duh...

@townsenk64 yep, known issue

https://redmine.pfsense.org/issues/13126

fix should be in the next snapshot or you can use system patches to apply the commit now

@auroramus
The source port of the requests is not specific, it's dynamic and can be any. So you have to set it to "any".

To avoid that pfSense show its web GUI when access it, change its listening port in System > Advanced> Admin Access to another one.

@vortex21 said in Reflection NAT using WAN Address as Source IP:

I have configured Reflection NAT in my lab to test a DNS View problem. The DNS server is configured with an internal LAN IP address and has two DNS views, all queries from the internal lan are processed on the DNS Internal view.

I'm wondering about the reason for using NAT reflection.
Why don't you simply forward packets to the DNS servers.

Is possible to get Reflection NAT to use the WAN address as the source address or do I have to create individual NAT rules?

Yes, you will need to add an outbound NAT rule for that.

You might have to switch into hybrid mode if the outbound NAT is still working in automatic.
Add a rule and limit the protocoll to TCP/UDP and the port to 53 (or even 853 in case of DoT) and enter the DNS servers IP at destination, go down and select the WAN IP from the Translation address drop-down.

Anyway, when forwarding DNS requests, an outbound NAT rule will be needed as well.

@lasergecko said in Second IP Address - Everything works except for one program/PF:

For some reason, it looks like pfSense is prohibiting just Dev from reaching the Prod FQDN, but just via that method.

The only one part where pfSense can affect the FQDN is at DNS resolution, if you use the DNS resolver. But since you say it resolves correctly, I cannot think of any issue with pfSense.

As I got you, the only problem is to access the dev server from within the same LAN. However, this traffic doesn't doesn't pass pfSense, when the host name resolves the the servers internal IP address.

So I think, you should look for the reason on the server itself. Maybe its firewall is blocking access from LAN, maybe the server have set a wrong network mask so that he is sending responses to the gateway.
Possibly you can sniff the traffic to find out more about what's going on.

@steveits Ah, yes. Good point. So I guess the corresponding NAT-rule did not work while the forward was fine. I used tcpdump on the proxmox host to find out, that the vserver answered the TCP-SYN, but the pfense did not forward to the corresponding recepient.

When I edited the port forward and pointed the same port to the different IP, the handshake succeded. I used netcat listeners on both systems and used an otherwise blank system. So, I am at a loss why it worked in one case but not in the other.

Still, it could be external hypervisor rules. But rest assured, I checked them and they all applied to both IPs due to a /24 subnet.

@steveits

thank you. I will take a look at the documentation.

take care and have a great day.

Regards,
Mon

@johnpoz said in [44158 Port forward doesn't seem to work]

As to switch to secondary wan? For a port to be forwarded, pfsense needs to see the traffic hit the interface you setup the forward on.. How your overall network is setup - have no idea, or what you might have in front of pfsense that could limit something from the internet talking to a pfsense wan IP so it could forward traffic.

of course i made the NAT forward/outgoing and rules per the above but using the wan2 interface in place of wan one. the rules must be good, because when i switched, the device immediately went from symetric nat to none

wan2 connects to a cable modem so received the ip from the isp on the pfsense interface. that is the address i see on the hnt public ip address.

wan1 has a fritzbox connected via eth to a fibre converter. the ISP provides a pppoe connection with a vlan. (tried a direct connection using pppoe with j1900 but performance was terrible) The lan side of the fritzbox has a 192.168.x.x connection and the pfsense wan1 plugs to that. the hnt device public ip is the isp address on the fritzbox fibre converter side.

@fourie777 Look at you badasses sorting it out this long after the original post. Good work.

@martijnvw pfSense is really quite flexible but not so much a "click a checkbox" type of system. Give it some time and I expect you'll like it. And learn a lot as you said. :)

@viragomann said in Port forwarding problem (I did try following the troubleshooting guide):

Run Diagnostic > Packet Capture on WAN and initiate an access from outside to check out, if the DMZ is working.
From what I see til now, I don't think so.

Problem solved, my ISP enabled DMZ on the wrong router (that I have an account for). Cleared up the router details, DMZ now working and port forwarding works perfect. Thank you for your time!

@seantree
After removing the check and saving the interface settings, the block rule should be gone from WAN.
Additionally you need a pass rule for allowing the access. However, this should be added automatically by the shown port forwarding rule.

Consider that Quick floating rules ca override interface rules.

@felixcda That sounds like the HA setup has its own problems. Scan through the troubleshooting doc and maybe start another thread. You should be able to put the primary in persistent maintenance mode, or shut it off, and the other take over seamlessly. And go the other direction. I do it all the time and it's how updates are done. Your two routers are identical?

Make sure you are allowing your WAN to talk to private ip space.

Click on Interfaces, then on WAN, scroll down to the bottom for this:

private_ip.png

If that's checked you are going to have a hard time talking to the external non routable IPs. This particular problem has tripped me up many times over the years when I forgot about it.

Got it!

HQ_port_pass.png

I could see the port passing in on HQ. But still no dice.

branch_missing_port.png

I added this accept rule on the Branch side and now it talks!

Took me some wandering but now I understand. Thanks @viragomann !

Ignore. I blundered my way through getting it right. Thanks for your time.

--Richard

@pacopito22
Yeah, agree. It should use the VIP on WAN.
You should reboot pfSense after adding outbound NAT rules.
Maybe it also helps to kill the states.

But the ping is not going to port 8080. This is TCP protocol as the state table is showing. Ping uses ICMP.

@rafamello said in Pure NAT:

For this to work I have to enable Pure Nat in :
System / Advanced / Firewall & NAT, correct?

Technically, that setting applies to ALL rules. If you only want reflection on some rules, you can leave the above disabled and on that one NAT rule change "NAT reflection" from "system default" to one of the Enable options.

@akuma1x Yeah - posted on the forum but no reply yet.....ive loaded wireshark on but still working out how to use it...!

Just gave pfsense a shot.
MIgration of my current setup with Plex and all, but after setting up pfsense and port-forward to Plex, I ran into a problem.
Remote access didn't work. Tautuilli couldn't verify the PMS.

I tried all suggested methods - uPnP - Port Forward in-out - Custom Option private-domain . . e.t.c. -> no luck.

Too much work at the very beginning of a clean install with 1 (one) port forward to work, that doesn't.

@comfy Fixed my own problem last night...seemed to be something on my managed switch which was stopping the traffic - transfered to an unmanaged switch and it started working.

@rlmalisz said in Cannot reach DMZ servers via external addresses:

setting NAT reflection

There is another solution, no reflection needed.
Use a "host override".

On the outside, the Internet, mail.yourserver.tld point to your (a) WAN address.
On the inside, a "host override" like a.spanou@add-assoc = IP address makes all your internal mail clients happy.

@viragomann
OMG I feel so stupid. I forgot that I had to put in https in the address instead of http. Thanks for all of your help.

@phlmike The same format of file? I would think so.

That doc page says, "For a URL Table alias, the drop-down list after the / controls how many days must pass before the contents of the alias are re-fetched from the stored URL by the firewall. When the time comes, the alias contents will be updated overnight by a script which re-fetches the data."

Thank you for your response.
I set the p2 to use a single address for NAT/BINAT translation and it works perfectly!
Thank you!

@inukollu
You can use any address you have assigned to pfSense interfaces for outbound connection.

However, I don't see why its not possibly to go out with the default WAN IP, even if it's private. Seems something on the ISP site.

To change the outbound source address you have to configure a rule in Firewall > NAT > Outbound.
I guess, you might have already have switched it to the hybrid or manual mode and added rules for the LAN network to get the outbound work.
So also add a rule for the source 127.0.0.0/8 to WAN interface and set any of your public IPs for translation.

@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0:

I have removed all non-essential packages. I have deleted and recreated the configuration multiple times.

Have you tried the most hidden solution, the one that ctually always works :
After a fresh install of pfSense : do nothing. Do not even change the password, just do plain nothing. Dont even run the the initial Wizard who makes pople think they have to give DNS servers because that is not the case.
pfSense has a resolver, so it works out of the box. DNS will work out of the box.

@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0:

My port forward to my DNS server isn't working.

You have DNS resolver or forwarder on your LAN that you want to use ?
Like a pi-hole or something ?
Or do you have contract with 9.9.9.9 and they want all yuor private DNS requests ?
Why do you think you need a DNS to forward to ?

@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0:

I have three other port forwards that are still working, but not port 53.

You forward port 53 from where to where ?
You forward UDP, or TCP, or both ?

@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0:

I run an external port scan

DNS traffic is outbound, not inbound ....
Right ?

@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0:

I have double-checked with my ISP to make sure they're not blocking it. NO JOY.

They wouldn't do that.
Blocking your "UDP port 53" access to the Internet is nearly the same as cutting the WAN wire.

@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0:

Could there be an issue with the latest release (2.60)?

Yep, No yoke. There is one.
If you use the captive portal, and you use limiters ( see the many recent forum posts about this subject) then it might look like the resolver isn't working an ymore. This means : no more DNS.
Work around : remove all limiters.
If you use the captive portal : install
8aaa7629-91fb-4536-8fc7-fe905df5835f-image.png

and apply the build in Captive portal patch.

@bmcneil
There is nothing special with multi WAN, except the failover group.

When your WAN are configured as DHCP client, the gateways are set automatically. Otherwise with static IP state the gateway in the interface settings.

For the failover group go to System > Routing > Gateway Groups and create a new group wherein you set the preferred gateway as Tier 1 and the second as Tier 2.The trigger level "member down" should fit your needs. State a name for the group and save the settings.
Then go to the gateways tab and set the failover group as default gateway and save this.

The proper outbound NAT rule should be added automatically by pfSense for both WANs, if the NAT is in automatic mode.
With this settings you should already have internet access from inside your network over both WANs.

For accessing your pfSense from the internet in case of a failover you have to switch the WAN IP on the client side. For instance you can use DynDNS which can be updated with the actual working WAN IP by pfSense.

A VPN client like OpenVPN is also capable to switch the server IP itself if one is not responding. So you can also use static IP or host names here.

@kilogica said in Reach LAN from WAN through ISP router and VPN:

Otherwise, could it be safer if I'll leave the router IP out of the rule?

As there is no need to give the router (or the ISP coming in through it) any access to your network that's a good decision in my opinion.

If I understood the basics, masquerading makes all the packets forwarded as they're coming from my ISP router IP, if I block the access to the LAN behind pfSense to that specific IP it may be good, right?

This all depends on how your router works, if it does masquerading on inbound traffic or not. If it does there should be an option to disable it, but I don't know.
Imagine it does, then the block rule would block forwarded VPN traffic as well. So you will have configure your rules in a proper order to pass what you need and block the rest.

So just check out if the router does masquerading. Forward traffic to pfSense WAN IP. Then start a packet capture on pfSense WAN (Diagnostic > Packet Capture) and trigger a traffic from outside.