Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 8 replies
  • Subscribers 0 subscribers
  • Views 2073 views
  • Users 0 members are here
Options
Suggested

[8.281][QUESTION][ANSWERED] BGP routes not being loaded 8.281

DCoulson
I am trying out BGP, using peers on the other end of SSL-VPN tunnels. I have the peering working, and I am able to advertise routes from my Astaro FW to the remote peer (Quagga running on a RHEL box), but I am not receiving routes from the peer properly.

This is the output from bgpd on my Astaro:

fw-1# sh ip bgp neighbors 10.2.0.1 received-routes 
BGP table version is 0, local router ID is 10.2.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.250.0.0/16    10.2.0.1                 0    100      0 64525 i
*> 10.250.52.0/23   10.2.0.1                 0    100      0 64525 i
*> 172.29.200.0/22  10.2.0.1                 0    100      0 64525 i

Total number of prefixes 3    
fw-1# sh ip bgp neighbors 10.2.0.1 routes 

I couldn't see any obvious reason from the logs why the received routes were not being used. I am running eBGP with no prefix-filters or route-maps (at least on the Astaro side).

Any ideas? I've not tried earlier beta releases, but willing to reinstall and rollback an update or two to troubleshoot.
  • 0 
    Astaro Beta Report
    --------------------------------
    Version: 8.281
    Type: QUESTION
    State: ANSWERED
    Reporter: DCoulson
    Contributor: 
    MantisID: 
    Target version: 
    Fixed in version: 
    --------------------------------

  • 0
    Hi DCoulson,

    congratulations, seems you are the first one running BGP on the UBB! [:)]

    Looks like the peer 10.2.0.1 is not reachable directly from the ASG.
    On tun interfaces, the remote BGP address should always be the Point-To-Point address.

    Cheers
     Ulrich
  • 0 in reply to da_merlin

    Looks like the peer 10.2.0.1 is not reachable directly from the ASG.
    On tun interfaces, the remote BGP address should always be the Point-To-Point address.


    Routes I have defined on Astaro as part of the SSL-VPN configuration have a next-hop of the ptp IP on tun0:

    # ip ro get 10.250.0.0
    10.250.0.0 via 10.3.251.2 dev tun0  src 10.3.251.1 
        cache  mtu 1500 advmss 1460 hoplimit 64

    # ifconfig tun0
    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
              inet addr:10.3.251.1  P-t-P:10.3.251.2  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:1328737 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1287545 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100 
              RX bytes:354382132 (337.9 Mb)  TX bytes:100968824 (96.2 Mb)

    The tun0 interface on the remote end of the tunnel looks like this:

    # ifconfig tun0
    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
              inet addr:10.2.0.1  P-t-P:10.3.251.1  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:1282545 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1320875 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100 
              RX bytes:100638354 (95.9 MiB)  TX bytes:345725205 (329.7 MiB)

    Note that 10.2.0.1 is a static IP defined as part of the SSL-VPN tunnel configuration. On the Astaro I have a route to 10.2.0.1:

    # ip ro get 10.2.0.1
    10.2.0.1 via 10.3.251.2 dev tun0  src 10.3.251.1 
        cache  mtu 1500 advmss 1460 hoplimit 64

    I'm starting to think BGP over SSL-VPN tunnel is not going to work right due to the 'shared' tun0 interface - I have no idea what mechanism routes tun0 traffic to the correct tunnel, as my existing static routed tunnels all have their next-hop set to the tun0 ptp IP, even when the end points are different tunnels:

    172.29.202.0/24 via 10.3.251.2 dev tun0 
    172.29.205.0/24 via 10.3.251.2 dev tun0 

    In this case, those two subnets are routed to different SSL-VPN endpoints, but from the Astaro the route looks the same.

    I'm going to go look at some OpenVPN documentation now [:)]
  • 0
    OpenVPN on the Astaro uses one tun interface for server connections and one
    tun interface for each client connection.

    So better run the Astaro in client mode here. Ensure that on the Astaro the
    PtP address is your BGP neighbor address and the remote side uses the PtP
    Address as their remote neighbor address.

    Otherwise BGP thinks they cant directly speak with each other and
    will not install the BGP routes.

    Cheers
     Ulrich
  • 0
    Unfortunately because many of the other ends of the SSL-VPN tunnels are behind NAT or on dynamic IPs, I can't switch around the initiator end-point of the tunnels.

    Are there any other options for dynamic routing via SSL-VPN tunnels?
  • 0
    If you have only one tunnel then it should be fine, just change the neighbors addresses to the PtP addresses, as I wrote.

    What do you want to archive? How many routers do you have and how are they connected to each other?

    Cheers
     Ulrich
  • 0
    Unfortunately I can't reverse the direction of the tunnels, as many of them are on dynamic IP addresses and behind NAT. I only have 7 SSL-VPN tunnels, but none of them are Astaro devices (OpenVPN or RHEL or SuSE in most cases).

    My goal was to utilize BGP for tunnel redundancy in a number of environments, where two or more devices would initiate SSL-VPN into my Astaro and announce routes. I could not figure out how to set a route weight when multiple tunnels route to the same end-point.
  • 0
    You could try to setup PPTP and operate BGP over the PPTP links.
    Or install RED boxes on these locations and use BGP.

    The other way would be to detect dead systems and establish the SSL tunnels
    only if they are needed...

    Cheers
     Ulrich
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?