Re: OSPF over gif on top of IPsec transport -current

Atanas Vladimirov Sat, 10 Mar 2018 11:31:11 -0800

On 2018-03-10 00:01, Remi Locherer wrote:

On Fri, Mar 09, 2018 at 06:13:10PM +0100, Remi Locherer wrote:

On Sun, Mar 04, 2018 at 01:08:21PM +0200, Atanas Vladimirov wrote:
> Hi,
>
> I can't make OSPF to work on gif over IPsec.
> With tcpdump on gif I see the OSPFv2-hello only from localhost:
>
> # R1
> [ns]~$ tcpdump -nei gif0
> tcpdump: listening on gif0, link-type LOOP
> 23:19:29.181685 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid
> 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1]
> 23:19:39.192025 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid
> 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1]
> 23:19:49.202372 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid
> 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1]
> 23:19:59.212730 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid
> 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1]
> 23:20:09.223064 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid
> 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1]
> 23:20:19.233393 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid
> 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1]
>
> # R2
> [hodor]~$ tcpdump -nei gif0
> tcpdump: listening on gif0, link-type LOOP
> 12:51:59.316704 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone [tos 0xc0] [ttl 1]
> 12:52:09.327002 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone [tos 0xc0] [ttl 1]
> 12:52:19.337314 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone [tos 0xc0] [ttl 1]
>
> While on enc0 both hello's appears (not sure if `bad ip cksum` is the reason
> for my issues):
>
> # R1
> [ns]~$ tcpdump -nvi enc0
> tcpdump: listening on enc0, link-type ENC
> 12:24:37.625873 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 >
> 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1]
> (id 25841, len 64) (ttl 60, id 37752, len 84)
> 12:24:41.882173 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 >
> 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid 192.168.1.1
> backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1]
> (id 27818, len 64) (ttl 64, id 60563, len 84, bad ip cksum 32d7! -> c614)
> 12:24:47.636188 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 >
> 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1]
> (id 36067, len 64) (ttl 60, id 65348, len 84)
> 12:24:51.892467 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 >
> 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid 192.168.1.1
> backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1]
> (id 5127, len 64) (ttl 64, id 12476, len 84, bad ip cksum 201! -> 81ec)
> 12:24:57.646535 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 >
> 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1]
> (id 39220, len 64) (ttl 60, id 1938, len 84)
>
> # R2
> [hodor]~$ tcpdump -nvi enc0 | grep OSPF
> tcpdump: listening on enc0, link-type ENC
> 12:28:57.894007 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 >
> 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1]
> (id 3667, len 64) (ttl 64, id 14037, len 84, bad ip cksum 2b6d! -> 7bd3)
> 12:29:02.151763 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 >
> 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid 192.168.1.1
> backbone E mask 25
> 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 16974, len
> 64) (ttl 60, id 21648, len 84)
> 12:29:07.904315 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 >
> 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone E mask 255
> .255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 45590, len 64)
> (ttl 64, id 35262, len 84, bad ip cksum 2743! -> 28ea)
> 12:29:12.162049 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 >
> 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid 192.168.1.1
> backbone E mask 25
> 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 19966, len
> 64) (ttl 60, id 3134, len 84)
> 12:29:17.914621 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 >
> 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello  44: rtrid 172.16.1.1
> backbone E mask 255
> .255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 36161, len 64)
> (ttl 64, id 53105, len 84, bad ip cksum fcb8! -> e336)
> 12:29:22.172468 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 >
> 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello  44: rtrid 192.168.1.1
> backbone E mask 25
> 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 36221, len
> 64) (ttl 60, id 29514, len 84)
>
> If I set a static routes the regular traffic flows as it should.
>
> The configs are the same on both routers:
>
> # R1
> [ns]~$ doas cat /etc/ipsec.conf
> local_ip="95.87.227.232"
> remote_ip="93.123.39.67"
> ike esp transport from $local_ip to $remote_ip
>
> # R2
> [hodor]~$ doas cat /etc/ipsec.conf
> local_ip="93.123.39.67"
> remote_ip="95.87.227.232"
> ike esp transport from $local_ip to $remote_ip
>
> # R1
> [ns]~$ doas cat /etc/hostname.gif0
> up
> mtu 1400
> tunnel 95.87.227.232 93.123.39.67
> inet 10.255.255.2/32
> dest 10.255.255.1
>
> # R2
> [hodor]~$ doas cat /etc/hostname.gif0
> up
> mtu 1400
> tunnel 93.123.39.67 95.87.227.232
> inet 10.255.255.1/32
> dest 10.255.255.2
>
> # R1
> [ns]~$ doas cat /etc/ospfd.conf
> # $OpenBSD: ospfd.conf,v 1.1 2014/07/11 16:36:35 deraadt Exp $
>
> # macros
> password="secret"
>
> # global configuration
>  router-id 192.168.1.1
>  fib-update yes
>  redistribute connected
>
> # areas
> area 0.0.0.0 {
>         interface gif0
> }
>
> # R2
> [hodor]~$ doas cat /etc/ospfd.conf
> # $OpenBSD: ospfd.conf,v 1.1 2014/07/11 16:36:35 deraadt Exp $
>
> # macros
> password="secret"
>
> # global configuration
>  router-id 172.16.1.1
>  fib-update yes
>  redistribute connected
>
> # areas
> area 0.0.0.0 {
>         interface vether0
>         interface gif0
> }
>
> # R1
> [ns]~$ ospfctl sh nei
> ID              Pri State        DeadTime Address         Iface     Uptime
>
> # R1
> [ns]~$ ospfctl sh int
> Interface   Address            State  HelloTimer Linkstate  Uptime    nc  ac
> gif0        10.255.255.2/32    P2P    00:00:04   unknown    00:15:37   0   0
>
> # R2
> [hodor]~$ ospfctl sh nei
> ID              Pri State        DeadTime Address         Iface     Uptime
> 172.16.1.9      1   FULL/DR      00:00:36 172.16.1.9      vether0   02:10:14
>
> # R2
> [hodor]~$ ospfctl sh int
> Interface   Address            State  HelloTimer Linkstate  Uptime    nc  ac
> gif0        10.255.255.1/32    P2P    00:00:04   unknown    02:10:24   0   0
> vether0     172.16.1.1/24      BCKUP  00:00:09   active     02:10:24   1   1
>
> Please, let me know if I'm doing something wrong/stupid or this is bug
> somewhere in the stack.


I applied your configs to newly created VMs with 6.2-beta from today
(pf disabled). I see the same with tcpdump as you do.

Then I tried this:
- the OSPF adjacency comes up when I disable IPsec
- when I replace gif with gre ospfd is happy (with IPsec active)
  (sysctl net.inet.gre.allow=1; mv /etc/hostname.{gif0,gre0})

I have a similar setup in production on 6.2 (with tunneldomain addedto the

mix). This works.

To me this looks like a regression when gif is used with IPsec.


With below diff the setup works as expected: tcpdump shows OSPF hellos
on gif0 and ospfd sees the neighbour.

I don't think it's the correct fix though.


Index: if_gif.c
===================================================================
RCS file: /cvs/src/sys/net/if_gif.c,v
retrieving revision 1.112
diff -u -p -r1.112 if_gif.c
--- if_gif.c    28 Feb 2018 23:28:05 -0000      1.112
+++ if_gif.c    9 Mar 2018 20:52:46 -0000
@@ -745,8 +745,8 @@ gif_input(struct gif_tunnel *key, struct
        }

        /* XXX What if we run transport-mode IPsec to protect gif tunnel ? */
-       if (m->m_flags & (M_AUTH | M_CONF))
-               return (-1);
+       //if (m->m_flags & (M_AUTH | M_CONF))
+       //      return (-1);

        key->t_rtableid = m->m_pkthdr.ph_rtableid;


Hi Remi,

Thanks for confirming that there is an issue and I'm not doing somethingwrong on my side.

I'll try the diff as soon as possible.
BR,
Atanas

Re: OSPF over gif on top of IPsec transport -current

Reply via email to