Yes, you can set a source IP (or an alias containing several IPs) in either the port forward directly or in the firewall rule filtering traffic forwarded by it. Steve

You sir are my new best freind THANKS SOOOOOOOOO MUCH! :D It was trying to route everything out a Management VLAN at our Provider :) Looks like it also fixed some of our VPN issues and other things. Hope this thread helps someone who may also be in the same situation.

GREAT !!! THANKS !!!

@rico said in DMZ server not getting the internet: Wow, this is a lot of Youtube tabs. And that's exactly the problem. People only replicate what others (oftentimes with shady knowledge) show on YT. They don't read manuals or docs anymore and try to understand how it's working. And the result is a not working config without the slightest cue where to look and how to solve it. @surajitit said in DMZ server not getting the internet: Need help as soon as possible. Really? ASAP is here: https://www.netgate.com/support/

Ok that EXPLAINS it ;) your "gateway" is the IP of your isp device, ie the device you talk to when you get to the internet - its their router your router is connected too.. So yes that octet would be different but would be in the same network. As to not pushing traffic through your vpn - make sure you do not pull routes in the client config, and then just policy route what you want to go through the vpn.

Ok, so in this configuration it seems that the best solution is to create a second VM running on the same physical NIC as the LAN connection. I launched a Fedora VM, configured a second NIC reaching to the first VM as the gateway and immediately gained access to the webConfigurator. Anyone have an idea as to why this doesn't work from the host machine?

Hi, While I have found a work-around in this particular instance - by reducing the header information in the SIP request, anyone sending UDP out on a WAN with a lower MTU than the LAN might run into this issue. This might affect VPN links as well as VOIP. Typically intranet LANs run 1500 byte MTU and VDSL/Fibre can often have a slightly smaller MTU. If you do have an issue with WAN outbound UDP, running tcpdump on the WAN leg and loading the file into wireshark to look for the source address being transmitted out of the firewall. [image: 1537862025044-b7c16e8e-6480-442a-a494-9ccc0254be79-image-resized.png] If you see the LAN source address, then you have the issue. There may be a config setting that will change the behaviour, however if this cannot be found,the packets will be dropped by the first internet router that sees them as private non-routable addresses are just that. Regards Simon

I figured it out. I needed to use 1:1 NAT for the routers ip.

The 1:1 page is for the inbound connection. It can get crossed up if you do that manually, so traffic comes in one IP and the reply is sent out another. That generally doesn't work since the other end drops the reply packets. I'm pretty sure pfSense will just automatically do it right. If you can connect out from the servers using 1:1 then connect out to whatismyip.org or something and you can see what IP you're connecting out on. On the outbound page what I was trying to say was that any rules entered there are processed in order, like firewall rules.

Ok, I found the problem. It was the internet gateway or upstream(as you said). I reinstalled the OS and the exposed host function worked again. For some reason it still shows 0 opened port, but hey it works! Thanks for your quick and professional help!

Your rules have to pass traffic to 192.168.1.11 not WAN Address. Not sure how you ended up there considering you have Add associated filter rule selected and it most certainly would not create a rule like that.

If you are interested I can provide a secure upload link outside of the forum. I generally like to see the exact rules that cause unexpected behavior. Kind of like seeking closure and understanding.

@derelict appreciate the response. A second reading of your comment straightened me out. Your kind hand holding has earned netgate a customer!