iBGP stuck in connect state

[Brooks Swinnerton]

Ah ha, it was the firewall. It's always the firewall.

On Wed, Dec 5, 2018 at 11:51 PM Brooks Swinnerton <bswinnerton at gmail.com>
wrote:

> Hello,
>
> I'm having trouble configuring two BIRD instances to talk to one another
> over a wireguard tunnel with iBGP. They both stay in a `Connect` state.
>
> With debug <protocol> all, I only see:
>
> ```
> Dec 05 23:31:32 border bird[3460]: foo: Connecting to 169.254.2.2 from
> local address 169.254.3.3
> Dec 05 23:33:19 border bird[3460]: foo: Connecting to 169.254.2.2 from
> local address 169.254.3.3
> Dec 05 23:35:13 border bird[3460]: foo: Connecting to 169.254.2.2 from
> local address 169.254.3.3
> ```
>
> The wireguard tunnel is up, and each side can ping the other:
>
> ```
> PING 169.254.2.2 (169.254.2.2) 56(84) bytes of data.
> 64 bytes from 169.254.2.2: icmp_seq=1 ttl=64 time=66.7 ms
> 64 bytes from 169.254.2.2: icmp_seq=2 ttl=64 time=66.6 ms
> 64 bytes from 169.254.2.2: icmp_seq=3 ttl=64 time=66.8 ms
> ```
>
> ```
> PING 169.254.3.3 (169.254.3.3) 56(84) bytes of data.
> 64 bytes from 169.254.3.3: icmp_seq=1 ttl=64 time=66.5 ms
> 64 bytes from 169.254.3.3: icmp_seq=2 ttl=64 time=66.2 ms
> 64 bytes from 169.254.3.3: icmp_seq=3 ttl=64 time=66.3 ms
> ```
>
> I can even see some BGP traffic when doing a tcpdump:
>
> ```
> 23:44:16.487852 ip: (tos 0xc0, ttl 64, id 40780, offset 0, flags [DF],
> proto TCP (6), length 60)
>     169.254.3.3.53585 > 169.254.2.2.179: Flags [S], cksum 0x5930
> (incorrect -> 0x61e7), seq 4023371188, win 27600, options [mss
> 1380,sackOK,TS val 891392 ecr
> 0,nop,wscale 7], length 0
> 23:44:16.989732 ip: (tos 0xc0, ttl 64, id 29307, offset 0, flags [DF],
> proto TCP (6), length 60)
>     169.254.2.2.46081 > 169.254.3.3.179: Flags [S], cksum 0x3ae5
> (correct), seq 156366469, win 27600, options [mss 1380,sackOK,TS val 889856
> ecr 0,nop,wscale
> 7], length 0
> 23:44:18.535863 ip: (class 0xc0, flowlabel 0xe9696, hlim 64, next-header
> TCP (6) payload length: 40) fd00:169:254:3::3.47019 >
> fd00:169:254:2::2.179: Flags [S], cksum 0x01b4 (incorrect -> 0x5b17), seq
> 1562824692, win 27200, options [mss 1360,sackOK,TS val 891904 ecr
> 0,nop,wscale 7], length 0
> 23:44:33.117481 ip: (tos 0xc0, ttl 64, id 29308, offset 0, flags [DF],
> proto TCP (6), length 60)
>     169.254.2.2.46081 > 169.254.3.3.179: Flags [S], cksum 0x2b25
> (correct), seq 156366469, win 27600, options [mss 1380,sackOK,TS val 893888
> ecr 0,nop,wscale 7], length 0
> 23:44:37.610488 ip: (class 0xc0, flowlabel 0xeaf06, hlim 64, next-header
> TCP (6) payload length: 40) fd00:169:254:2::2.36355 >
> fd00:169:254:3::3.179: Flags [S], cksum 0x243b (correct), seq 476210459,
> win 27200, options [mss 1360,sackOK,TS val 895010 ecr 0,nop,wscale 7],
> length 0
> 23:44:38.621468 ip: (class 0xc0, flowlabel 0xd3b4f, hlim 64, next-header
> TCP (6) payload length: 40) fd00:169:254:2::2.36355 >
> fd00:169:254:3::3.179: Flags [S], cksum 0x233d (correct), seq 476210459,
> win 27200, options [mss 1360,sackOK,TS val 895264 ecr 0,nop,wscale 7],
> length 0
> 23:44:40.637418 ip: (class 0xc0, flowlabel 0xd41b0, hlim 64, next-header
> TCP (6) payload length: 40) fd00:169:254:2::2.36355 >
> fd00:169:254:3::3.179: Flags [S], cksum 0x2145 (correct), seq 476210459,
> win 27200, options [mss 1360,sackOK,TS val 895768 ecr 0,nop,wscale 7],
> length 0
> 23:44:44.893305 ip: (class 0xc0, flowlabel 0xcc08e, hlim 64, next-header
> TCP (6) payload length: 40) fd00:169:254:2::2.36355 >
> fd00:169:254:3::3.179: Flags [S], cksum 0x1d1d (correct), seq 476210459,
> win 27200, options [mss 1360,sackOK,TS val 896832 ecr 0,nop,wscale 7],
> length 0
> ```
>
> The bird.conf file is identical between hosts can be found in:
> https://gist.github.com/bswinnerton/9ffa236a55f120ba9491658ae74a841a.
>
> Does anything seem amiss? What's odd is that I can establish iBGP
> connections with other BGP routers that are not running BIRD with the exact
> same iBGP peer configuration.
>
> $ sudo birdc -v
> 0001 BIRD 2.0.2 ready.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181206/0dff0c0b/attachment.html>