Netgate m1n1wall

Author Topic: BGP routes across IPSec tunnel (2.0 RC1)  (Read 1590 times)

0 Members and 1 Guest are viewing this topic.

Offline bradenmcg

  • Jr. Member
  • **
  • Posts: 97
  • AS13697
    • View Profile
BGP routes across IPSec tunnel (2.0 RC1)
« on: May 23, 2011, 11:52:18 pm »
I am either doing something incorrectly here, or pfsense can't (yet?) do what I want.

I'm running 2.0 RC1.  I have the OpenBGP package installed.

I have an IPSec tunnel up between my pfSense box and my Palo Alto PA2020 at the office.  Tunnel is fine, I can pass traffic in to my network there.

I had to add a static route on my pfSense config to allow the router itself to reach the remote DNS servers at the office.  Route is 192.168.x.0/24 (office subnet) routed through my LAN default gateway (aka the pfSense box itself).  This is as described in the FAQs around here.

My BGP configuration also seems to be correct.  The BGP connection is alive, and routes are coming down the pipe.

However, the routes come in and the next hop gateway shows my pfSense's LAN gateway, presumably due to the static route I have to add to allow pf to access the remote BGP peer and such.

I'll show you the tables and it should make more sense.
First, you can see the BGP is working:
Neighbor                   AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
OFFICE          65001        260        224     0 01:44:35     20


Here's the forwarded BGP table from the office -- note that many of these routes are coming from a different BGP peer (my ISP, the office has an MPLS-based "VPN" and the ISP hands the routes off to make my life easier).  The whole point of this exercise is for me to be able to reach the remote routes from home, across my IPSec to the office, without hand-entering all of them.

flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination          gateway          lpref   med aspath origin
*>    10.0.5.0/24          192.168.1.1        100     0 65001 65000 22958 i
*>    10.0.86.0/24         192.168.1.1        100     0 65001 65000 22958 i
*>    10.0.92.0/24         192.168.1.1        100     0 65001 65000 22958 i
*>    10.0.93.0/24         192.168.1.1        100     0 65001 65000 22958 ?
*>    10.0.106.0/24        192.168.1.1        100     0 65001 65000 22958 ?
*>    10.0.107.0/24        192.168.1.1        100     0 65001 65000 22958 i
*>    192.168.5.0/24       192.168.1.1        100     0 65001 65000 22958 i
*>    192.168.86.0/24      192.168.1.1        100     0 65001 65000 22958 i
*>    192.168.92.0/24      192.168.1.1        100     0 65001 65000 22958 i
*>    192.168.93.0/24      192.168.1.1        100     0 65001 65000 22958 ?
*>    192.168.106.0/24     192.168.1.1        100     0 65001 65000 22958 ?
*>    192.168.107.0/24     192.168.1.1        100     0 65001 65000 22958 i
*>    192.168.116.0/24     192.168.1.1        100     0 65001 65000 22958 i


I've omitted a few public IPs but you get the idea.

However, here is what the BGP Forwarding table looks like on my pf:
flags: * = valid, B = BGP, C = Connected, S = Static
       N = BGP Nexthop reachable via this route
       r = reject route, b = blackhole route

flags prio destination          gateway
*B      48 10.0.5.0/24          192.168.42.1
*B      48 10.0.86.0/24         192.168.42.1
*B      48 10.0.92.0/24         192.168.42.1
*B      48 10.0.93.0/24         192.168.42.1
*B      48 10.0.106.0/24        192.168.42.1
*B      48 10.0.107.0/24        192.168.42.1
*C       0 127.0.0.0/8          link#0
*C      48 127.0.0.1/32         link#6
*SN     48 192.168.1.0/24       192.168.42.1
*B      48 192.168.5.0/24       192.168.42.1
*C      48 192.168.42.0/24      link#2
*C      48 192.168.42.1/32      link#6
*B      48 192.168.86.0/24      192.168.42.1
*B      48 192.168.92.0/24      192.168.42.1
*B      48 192.168.93.0/24      192.168.42.1
*B      48 192.168.106.0/24     192.168.42.1
*B      48 192.168.107.0/24     192.168.42.1
*B      48 192.168.116.0/24     192.168.42.1


I've omitted public IPs above.  192.168.42.1 is my pf box.

If I try to traceroute any host in the remote subnets (the BGP advertised ones), here's an example:
traceroute to 192.168.5.1 (192.168.5.1), 64 hops max, 52 byte packets
 1  192.168.42.1  7.112 ms  9.974 ms  9.872 ms
 2  * * *
 3  * * 192.168.42.1  11.376 ms !H
 4  192.168.42.1  9.828 ms !H  9.991 ms !H  9.937 ms !H
 (this was from a Mac)

So obviously, there's a routing problem.  I'm not sure how to solve it, or if it is even solveable given that I need a routing hack in place in order to let the firewall itself talk to the remote subnet across the VPN...?

Again, I'm running 2.0 RC1.  If there are any fixes in a newer build I'm not averse to an update for that.
« Last Edit: May 24, 2011, 02:54:04 pm by bradenmcg »