Problem with TCP-MD5 packet encryption on multiple VLAN Interfaces



  • I thought I was going to have this happen after ermal fixed the last problem with TCP-MD5 because I was seeing it in my previous testing but I wanted to verify it,  and also reproduce it in the supported package of OpenBGP instead of in Quagga BGP.

    I have an application where I need to run BGP on 2 interfaces  these interfaces are VLAN interfaces on the same physical interface.  When I configure BGP for both interfaces with MD5-TCP encryption, only the 'first' interface gets the packet encryption the other one is passed in the clear.

    However if I do a test config where the second BGP interface is on a different physical interface, then both interfaces get packet encryption.

    This happens in both OpenBGPD and in using Quagga BGP Here is a reproducible setup for OpenBGP.

    Narrative:

    The idea is that pfsense1 is me,  and pfsense2 replicates my service provider.  Over the em1_vlan3 bgp interface I'm receiving routes of public ip's from the service provider but only advertising my interface ip (pretend it's a public ip) since i'm natting all the traffic. On the em1_vlan4 interface I'm receiving private network routes and advertising a private subnet behind me because i'm routing traffic instead of natting on that interface.

    pfsense1:

    
    em1_vlan3:  192.168.70.1/30
    em1_vlan4:  192.168.71.1/30
    em2: 192.168.80.1/24
    em3: 192.168.72.1/30
    
    

    pfsense2:

    
    em1_vlan3: 192.168.70.2/30
    em1_vlan4: 192.168.71.2/30
    em2: 192.168.81.1/24
    em3: 192.168.72.2/30
    
    

    pfsense1:

    
    AS 65432
    fib-update yes
    listen on 192.168.70.1
    listen on 192.168.71.1
    router-id 192.168.70.1
    network 192.168.70.0/30 set community 65432:100
    network 192.168.80.0/24 set community 65432:200
    network 192.168.71.0/30 set community 65432:200
    group "groupa" {
    remote-as 65431
    neighbor 192.168.70.2 {
    descr "networkA"
    tcp md5sig password _SH4KOw4I_El6Qjho4Dsd3wL
    announce all  
    local-address 192.168.70.1
    }
    }
    group "groupb" {
    remote-as 65431
    neighbor 192.168.71.2 {
    descr "networkB"
    tcp md5sig password QJCeVkW_c3mYicYAVqqVxKij
    announce all  
    local-address 192.168.71.1
    }
    }
    deny from any
    deny to any
    allow from 192.168.70.2
    allow to 192.168.70.2 community 65432:100
    allow from 192.168.71.2
    allow to 192.168.71.2 community 65432:200
    
    

    pfsense2:

    AS 65431
    fib-update yes
    listen on 192.168.70.2
    listen on 192.168.71.2
    router-id 192.168.70.2
    network 192.168.70.0/30 set community 65431:100
    network 192.168.81.0/24 set community 65431:100
    network 192.168.71.0/30 set community 65431:200
    network 192.168.82.0/24 set community 65431:200
    
    group "groupa" {
    remote-as 65432
    neighbor 192.168.70.1 {
    descr "networkA"
    tcp md5sig password _SH4KOw4I_El6Qjho4Dsd3wL
    announce all  
    local-address 192.168.70.2
    }
    }
    group "groupb" {
    remote-as 65432
    neighbor 192.168.71.1 {
    descr "networkB"
    tcp md5sig password QJCeVkW_c3mYicYAVqqVxKij
    announce all  
    local-address 192.168.71.2
    }
    }
    deny from any
    deny to any
    allow from 192.168.70.1
    allow to 192.168.70.1 community 65431:100
    allow from 192.168.71.1
    allow to 192.168.71.1 community 65431:200
    
    

    If you tcpdump on em1_vlan4 you will see that it's missing the MD5 signature.

    Now modify the configs above to use em3 by replacing 192.168.71.0/30 addresses with 192.168.72.0/30 addresses you will see that both em1_vlan3 and em3 both have MD5 signatures.



  • Can you tell me what you have with setkeyd -D? on working and not working case?



  • Well…

    I was working on re-doing the repro and collecting the data and it looks like bgp traffic on both vlan interfaces have the tcp signatures working in my test rig.

    I did notice that openbgpd does not do a good job cleaning up no longer needed entries to the SAD. And I worked my way up to the final config the first time.  Let me run some more scenarios and I'll report back.



  • You can disregard / close this problem report.

    I was not able to find a reproducible Issue.  I have everything working like I need at the moment.