@kpa:

No, that's not policy routing at all. What you need is a normal static route on pfSense with the WAN address of the inner router as the target for the traffic that going to the LAN of the inner firewall. Static routes are set at System->Routing->Static Routes.

Actually thats exactly what I try to admit :)

@kpa:

Additionally I hope you're using a transit network between pfSense and inner firewall with no hosts on it? Otherwise you have a broken network setup with asymmetric routing.

Yeah, a nice firewall transit network :)

My understanding of policy based routing, comes from Barracuda and Juniper. There it works on the routing and not on firewall level. So both ways are possible, in- and outbound. Posted a screen as an example.

barra_pbr.PNG
barra_pbr.PNG_thumb
barra_pbr2.PNG
barra_pbr2.PNG_thumb

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.

pfsensegw1.jpg
pfsensegw1.jpg_thumb
pfsensesr1.jpg
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