Ah. That makes perfect sense. You want to keep all VLAN tagged traffic physically separated for security purposes. Thanks!

Solved. Just wrong config. Need more accurate and not more. ( not edit files, chown and other, just config ) Good config must be: This file was created by the package manager. Do not edit! AS 65002 fib-update yes holdtime 30 listen on 0.0.0.0 router-id 192.168.56.101 network 192.168.57.0/24 group "GR_65001" { remote-as 65001 neighbor 192.168.56.201 { descr "to_as_65001" announce all  local-address 0.0.0.0 } } deny from any deny to any allow from 192.168.56.201 allow to 192.168.56.201 P.S. Log installation OpenBGPd at WEB-configurator Installing pfSense-pkg-OpenBGPD… Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Updating database digests format: .... done The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: pfSense-pkg-OpenBGPD: 0.11_9 [pfSense] openbgpd: 5.2.20121209_2 [pfSense] Number of packages to be installed: 2 155 KiB to be downloaded. [1/2] Fetching pfSense-pkg-OpenBGPD-0.11_9.txz: .. done [2/2] Fetching openbgpd-5.2.20121209_2.txz: …....... done Checking integrity... done (0 conflicting) [1/2] Installing openbgpd-5.2.20121209_2… ===> Creating groups. Creating group '_bgpd' with gid '130'. ===> Creating users Creating user '_bgpd' with uid '130'. [1/2] Extracting openbgpd-5.2.20121209_2: …...... done [2/2] Installing pfSense-pkg-OpenBGPD-0.11_9… Extracting pfSense-pkg-OpenBGPD-0.11_9: .......... done Saving updated package information... done. Loading package configuration... done. Configuring package components... Loading package instructions... Custom commands... Executing custom_php_resync_config_command()...done. Menu items... done. Services... done. Writing configuration... done. Message from openbgpd-5.2.20121209_2: OpenBGPD has been successfully installed. Configuration file must be created at /usr/local/etc/bgpd.conf and permission set to 0600. Cleaning up cache... done. Success Any question? Contact here: http://ciscooc.blogspot.ru/

@costasppc: Maybe use 8.8.4.4 as your monitor ip? Best regards Kostas Ahh! Thank you! That was the problem!!

Vlan managed switch

Been a while but I think you need to create phase 2 entries for the other subnets…

The gui changed at 2.3.0+ a little over a year ago.

If they are connected via VPN they should probably be speaking with each other directly from private network to private network without any NAT.

"The only constraint is that I have to "make due" with that firewall and it's 6 ports." Who says?  If you had a self built box and needed switch ports?  Why would you not have put in switch ports vs NICs?  Get yourself a small gig switch – they are pretty freaking tiny!!

Solved I made an extra vlan with rules and everything is ok delan009

Thanks for the link. Everything is working perfect now. I'm going to sleep like a baby tonight!!

Having the same issue.  Although this between the OpenVPN server and the client.  What happens is when the PfSense is rebooted and a client connects to the vpn none of the routes are pushed to the client, only after I go in to the OpenVPN configuration and click SAVE will it start working again even though the routes are still there. I think it could be the OpenVPN .conf file is overwritten after reboot and anything in the bottom box where you'd put you custom routes are discarded. 2.3.2-RELEASE (amd64) built on Tue Jul 19 12:44:43 CDT 2016 FreeBSD 10.3-RELEASE-p5 openvpn-2.3.11                Secure IP/Ethernet tunnel daemon openvpn-client-export-2.4.2_1  OpenVPN Client Export

pfSense Updates follow the routing table, not policy routing.

Hello, Not IPSec, so I don't know if it fits your needs, but OpenVPN, here: https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN Best regards Kostas

I just installed another host which is connected to the first pfsense and this host cannot ping 172.16.20.1 either, so this is not an OpenVPN issue but a routing issue. On the OpenVPN Interface (does also apply to the other server interface): 18:17:04.562619 IP 192.168.68.2 > 172.16.20.1: ICMP echo request, id 53527, seq 0, length 64 18:17:05.551177 IP 192.168.68.2 > 172.16.20.1: ICMP echo request, id 53527, seq 1, length 64 18:17:06.595303 IP 192.168.68.2 > 172.16.20.1: ICMP echo request, id 53527, seq 2, length 64 18:17:07.598748 IP 192.168.68.2 > 172.16.20.1: ICMP echo request, id 53527, seq 3, length 64 On the interface which connects both firewalls: 18:18:15.316407 IP 172.16.58.250 > xxx.xxx.xxx.193: ICMP echo request, id 21153, seq 5564, length 8 18:18:15.316952 IP 1xxx.xxx.xxx.193 > 172.16.58.250: ICMP echo reply, id 21153, seq 5564, length 8 18:18:15.321373 IP 172.16.58.250 > 172.16.58.254: ICMP echo request, id 21835, seq 5592, length 8 18:18:15.321385 IP 172.16.58.254 > 172.16.58.250: ICMP echo reply, id 21835, seq 5592, length 8 xxx.xxx.xxx.193 is the gateway IP of the public subnet. This also happens if I use an internal server which is not connected via OpenVPN. It looks like the backcoming packages are routed on the public gateway ip and not back to the subnet. I attached 2 pictures which show the gateway configuration and the static route. The selected interface is the interface where both pfSense(s) are connected. [image: pfsensegw1.jpg] [image: pfsensegw1.jpg_thumb] [image: pfsensesr1.jpg] [image: pfsensesr1.jpg_thumb]

There is no reason for it not to be working. Load Balancing does not combine two circuits into one. The only technology that can do that in pfSense is Multi-Link PPP. Load balancing distributes states across multiple links with the end goal of getting more of both circuits utilized. Did you enable sticky connections or anything like that? A single speed test site has never been a good way to test this. The last time someone said it didn't work I tested it with T-Rex. The results are here: https://forum.pfsense.org/index.php?topic=124373.msg697215#msg697215 That thread is probably worth reading. This too: https://portal.pfsense.org/docs/book/multiwan/index.html

I solved the HP part, running the following on the switch CLI: ****************************************************************************** * Copyright (c) 2010-2016 Hewlett Packard Enterprise Development LP          * * Without the owner's prior written consent,                                * * no decompiling or reverse-engineering shall be allowed.                    * ****************************************************************************** <hp>system-view System View: return to User View with Ctrl+Z. [HP]ip ttl-expires enable [HP]ip unreachables enable [HP]</hp> Reference: https://community.hpe.com/t5/Switches-Hubs-and-Modems/Troubles-with-traceroute-in-Switch-HP-5500g/td-p/5880679 Now, tracing the route to Google Public DNS ( 8.8.8.8 ) my router appears: # traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1  10.100.132.1 (10.100.132.1)  0.551 ms  0.773 ms  0.940 ms 2  * * * 3  187.86.158.121 (187.86.158.121)  6.439 ms  6.440 ms  6.437 ms 4  172.21.1.133 (172.21.1.133)  7.674 ms  7.676 ms  7.672 ms 5  172.22.100.137 (172.22.100.137)  7.667 ms  7.663 ms  7.659 ms 6  172.22.100.121 (172.22.100.121)  7.654 ms  2.738 ms  2.578 ms 7  ip-187-86-128-93.vetorialnet.com.br (187.86.128.93)  2.638 ms  2.641 ms  3.039 ms 8  177-101-203-189.static.stech.net.br (177.101.203.189)  8.913 ms  9.578 ms  10.419 ms 9  xgborder-rs-pae-01-xe-0-0-0.3300.stech.net.br (200.152.253.252)  11.026 ms  11.136 ms  11.506 ms 10  * * * 11  108.170.245.161 (108.170.245.161)  37.144 ms 108.170.245.129 (108.170.245.129)  36.718 ms * 12  209.85.242.119 (209.85.242.119)  36.232 ms * 72.14.238.221 (72.14.238.221)  36.333 ms 13  google-public-dns-a.google.com (8.8.8.8)  55.787 ms  55.838 ms  55.688 ms Maybe there is something like ttl-expires and/or unreachables for pfSense?