OpenVPN and OpenBGPD on pfSense 1.2.3
-
Hi,
Yesterday I spent hours getting OpenBGPD working with OpenVPN tunnels, but it just wouldn't work.
What I'm trying to do is the following (which actually works fine with pfSense 2.0 <-> pfSense 2.0, both NanoBSD):Site A (pfSense 2.0) Site B (pfSense 1.2.3) Tunnel 1: WAN1 ------- OVPN1-A ------ Internet ------- OVPN1-B ------- WAN1 Tunnel 2: WAN2 ------- OVPN2-A ------ Internet ------- OVPN2-B ------- WAN1 OVPN1-A: 192.168.168.0/30 (192.168.168.1) OVPN1-B: 192.168.168.0/30 (192.168.168.2) OVPN2-A: 192.168.168.4/30 (192.168.168.5) OVPN2-B: 192.168.168.4/30 (192.168.168.6)
They can ping each other fine and there are also, for the sake of this test, allow all from/to all firewall rules added at both sides. No remote subnet specified, because BGP should handle this.
Now I added OpenBGPD into the picture, which is configured as follows:
Site A bgpd.conf:
AS 65003 holdtime 20 listen on 0.0.0.0 router-id 192.168.128.32 network 192.168.128.0/23 group "group1" { remote-as 65005 neighbor 192.168.168.2 { descr "ovpn1" announce self set localpref 101 } neighbor 192.168.168.6 { descr "ovpn2" announce self } } deny from any deny to any allow from 192.168.168.2 allow to 192.168.168.2 allow from 192.168.168.6 allow to 192.168.168.6
Site B bgpd.conf:
AS 65005 holdtime 20 listen on 0.0.0.0 router-id 192.168.1.200 network 192.168.1.0/24 group "group1" { remote-as 65003 neighbor 192.168.168.1 { descr "ovpn1" announce self set localpref 101 } neighbor 192.168.168.5 { descr "ovpn2" announce self } } deny from any deny to any allow from 192.168.168.1 allow to 192.168.168.1 allow from 192.168.168.5 allow to 192.168.168.5
After starting / committing the configuration above, BGP will exchange it's status messages just fine, but gives the following error at site B:
bgpd[54280]: send_rtmsg: action 3, prefix 192.168.128.0/24: Network is unreachable
And indeed, this route is not listed in the routing table at site B. Adding a static route for it works fine. Then again, when OVPN1 gets down, it isn't able to update the routing table. It's important to know that the exact same configuration works perfectly well on two pfSense 2.0 boxes connected with each other.
Has anyone an idea what goes wrong here. We unfortunately can't upgrade site B to 2.0 since it's running om a very important production environment.
Thanks.