Gateway groups and other policy routing tricks are not available for traffic that originates from the firewall itself, they only work on traffic that enters the firewall via an interface from the outside. You can call it bug or otherwise but FreeBSD's packet filtering hooks can not re-route traffic that is already in the outgoing queue of an interface. Binding to an unused interface (like the igb3 in your case) is not going to work either because the traffic is still originating locally and never actually enters the incoming queue of the interface where it could be tagged for policy routing.

Does your remote side know it needs to go down the vpn connection to get to 192.168.100.. Sounds like you setup a roadwarrior connection.  You more than likely want a site to site if your connecting to sites together.

Cristal clear! Thank you very much for the time you took to resolve my problem and point me to the proper documentation.

i solved the issue. i just added the server in my captive portal to access the internet that i was trying to port forward.  thanks Derelict.

The same thing.

https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

If your seeing traffic to your wan with a dest of some random number, its prob just noise. I would suggest you use something like canyouseeme .org and test say port 80.. You should then see this traffic on your wan.  diag packet capture will validate that. As KOM points out use of VIP would be say if your ISP gave you multiple IPs to use.  On the LAN there really would never be a reason to setup a VIP, especially in a different network this would amount to trying to run multiple layer 3 on the same layer 2 which is a Borked config. If what your saying is that your isp gave you a rfc1918 address of say 192.168.1.100 and they forward all traffic to that public address to this IP.  You just need to setup pfsense wan IP with that IP, and point to the gateway they gave you.  Then forward whatever ports you want to the network your using behind pfsense on its lan, it could be a 10 network or a 172.16-31 network or even a different 192.168 network. This really should work out of the box with very min config.  Set your wan IP, set your lan IP and big bang zoom bobs your uncle.

Thank you for the reply. Your answer push me that think differently. And I solved the problem (I think so..) for OPENVPN side. I've just added a static rule for "IPv4 Tunnel Network" -30.0.0.0/24 for me- of OPENVPN into the server. Now I can access the server through the OPENVPN.

The real solution is to modify your internal DNS so that the hostnames resolve to their private IP, then have them use hostname.  If they insist on using IP addresses then they can feel free to use the internal IP address.

Hi, I So everything was working wonder full with the separation of the Ip but i just realized when it reboots for some odd reason it grabs as the WAN the 200.116.xx.xx when it shows clearly the WAN is the 181.xx.xx.xx, So when it reboots i have to disable the opt1 reboot then re enable the opt1( emailserver). So odd any ideas? Could it be the order of the re0-re2? Thank you Edit: i was looking at the system logs found something very odd.. Nov 7 22:36:04 php-fpm[21478]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 200.116.3.14XX -> 200.116.3.14XX - Restarting packages. Nov 7 22:36:02 php-fpm[21478]: /rc.newwanip: Creating rrd update script Nov 7 22:36:02 php-fpm[21478]: /rc.newwanip: Resyncing OpenVPN instances for interface EMAILSERVER. Nov 7 22:36:02 php-fpm[9836]: /interfaces.php: Creating rrd update script Nov 7 22:36:02 check_reload_status: Reloading filter Nov 7 22:36:00 check_reload_status: updating dyndns opt1 Nov 7 22:35:59 php-fpm[21478]: /rc.newwanip: rc.newwanip: on (IP address: 200.116.3.14XX) (interface: EMAILSERVER[opt1]) (real interface: re1). Nov 7 22:35:59 php-fpm[21478]: /rc.newwanip: rc.newwanip: Info: starting on re1. Nov 7 22:35:58 check_reload_status: Restarting ipsec tunnels Nov 7 22:35:58 check_reload_status: rc.newwanip starting re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 Nov 7 22:35:58 kernel: arpresolve: can't allocate llinfo for 200.116.3.X on re1 [image: Clipboarder.2016.11.07.png] [image: Clipboarder.2016.11.07.png_thumb]

@scorpious: …connected through a VPN. You are on a different ip range than your RDP host, right? When switching from your ASUS router you created a new network which your Win10 PC most probably detected as new. Did you set it to private? You need to create rules to allow inbound RDP attempts on your Win10 "firewall" from local as well as non-local clients.

Does Apple's Port settings for AT&T WiFi calling on secure networks post help you? I opened both UDP ports 500 and 4500 but still couldn't get it to work. I'd love to hear from someone who got AT&T WiFi Calling working and what all they had to do to pfsense.

I'd say what the error tells you is very useful.  Try using it in the forum search.

I'll read the tutorial and if all fails, start from scratch and make sure each rule works before moving to the next… Thanks a lot for your help.

#4326 is now in Feedback.