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!

How about you pose all of those screenshots instead. @mars said in TCP doesn't work through 1:1 virtual IP: 1:1 Virtual IP to LAN IP 192.168.7.100 Outbond 192.168.7.0/24 * * * Virtual IP public * I do not know why you would do this. 1:1 means just that. 1:1. It looks like you are also trying to outbound NAT the whole /24 to the same VIP which should work fine. But I honestly do not know what would happen in that case. @mars said in TCP doesn't work through 1:1 virtual IP: WAN rules IPv4 TCP/UDP * * ->LAN Net * * This also makes little sense.. You should be passing traffic to 192.168.7.100, not LAN net.

Enabling NAT Reflection fixed my issue.

Thanks that did the trick on the shared frontend had to add that and on the redirect to HTTPS sections Thank you so much

I found the solution with this rules : [image: 1530282966945-fcfe0fcc-c0bd-4fef-8c62-7f79c5065c3c-immagine-resized.png]  Thanks ... Andrea