For nearly a year now, we have multichannel numbers and 800 numbers from Hottelecom. When it was connected, it was a problem, but not significant, so the support service instantly decided everything. Have you contacted the support team?
You should check if you can see a mac address assigned to the IP entry in the arp cache of the host you're trying to ping.
No surprise that you can see the firewall's own interfaces in the arp cache. They're static.
Go check the arp cache again and then fix the l2 plumbing.
Cu
@Nono_ A DNS-Forwarder is nothing else than a stripped down resolver. The only difference is that unbound can do more than just resolve. Besides that even dnsmasq can hold host entries nowadays, but anyway...
When you tell a program to use 127.0.0.1 as its source address then the packet filters aren't applied to 127.0.0.1. There's a sysctl variable that needs to be set in order to enable this behaviour.
That's all.
No, you gotta tell the box on 127.20.0.4 to use pfSense to as a gateway so that it sends back the requests coming from the port forwarding back through the machine it came from.
Alternative would be to enable outbound (src) nat for all packets going towards .4 port 6540 to the firewall's IP. that way you're on the same subnet and .4 doesn't care.
The downside is that everything comes from pfSense and you do not know the real IP that tries to access .4.
cu
@muppet said in Error Loading Rules - Only when using an Alias in NAT rule:
here
I've created a bug report for it
I'm getting the same in 2.4.4 p3 and 2.4.5-RC, trying to do the same as you with redirecting DNS
Delete all the rules above and create a port forwarding rule:
Everything that hits the external interface's IP on port 5060 is forwarded to the PBX on 5060.
This should give you the main connection. Then check the udp port range the PBX uses for actual communication (RTP).
Forward those ports as well from external IP to the PBX.
If the RTP ports cannot be nailed down to reside in a certain range, check if the PBX can use a STUN server and if your provider offers one. If so, the PBX connects to the STUN server, does a handshake when it comes to ports and then uses those ports on the firewall (punches holes in the state table for said udp ports) and keeps them open and alive.
Tell your AP how to reach the other subnet via routing. Or just set the default gateway of the AP to be your pfSense and everything is fixed.
On the other hand you can setup some outgoing NAT on the interface where the AP is connected to like:
nat on $lan from $opt1_network to $lan_network -> ($lan)
So that you source nat everything going out on the lan network's interface coming from opt1's subnet to the IP of the lan_interface.
Are you testing from INSIDE the same network where the cameras are running?
If so, enable the NAT-reflection option that does NAT + PROXY.
I explained NAT-reflection in a different context here:
https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns/14
Cu
Glad you got it sorted - you really need to state up front what your using, be it hardware (make and type) or if your running on VM, if so what virtualization your using.
I see why mine worked. I had manually set an external address, which bypasses the check. If your actual WAN address is static (or reasonably so) you could set that in the UPnP options as well.
It doesn't look like the miniupnp folks are budging on it, and it isn't a recent behavior change: https://github.com/miniupnp/miniupnp/issues/298 -- Their "solution" is to let it use a STUN server to determine the external address, which is still not ideal.
Did you have to make any other changes? I have the same setup and can send a request from the private subnet, via pktcapture I can see it get through the LAN interface, out the WAN and the response back, but the client never gets the response back through the NAT.
While using pfctl to view your rule set can be a valuable tool, looking at /tmp/rules.debug can be much more straightforward. You would also have the benefits of things like comments that would immediately show you that you were looking at NAT Reflection rules.
A long shot. Have you checked that all ports are open in the local FW on the windows server?
If you are on the same network when you test internally you probably ain't using NAT-T so those ports might be closed
@james416 said in Port Forwarding Multi-Wan Issue on 1 Wan:
BellFibe is the default Gateway
Yeah.. That would be something to post in bold in your case..
I wish ISP's would get a clue..
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.