Problem with TCP-MD5 packet encryption on multiple VLAN Interfaces

jeffbearer

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.

eri--

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

jeffbearer

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.

jeffbearer

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.