GIF interface and Routing Serious Unexpected behavior

[sven falempin]

Dear Tech Reader,
Maybe this would be misc but i am trying to avoid some useless answer.
This is openbsd 5.8 patched ( -r OPENBSD_5_8 )
All my block rule log.
Nothing appear in tcpdump -teni pflog0
But pf drop packet (set skip or pfctl -d) solve problem.
[0]-[blue]-[/cloudgate]
# ping -c2 -w2 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=0.894 ms
64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=0.966 ms
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.894/0.930/0.966/0.036 ms
[0]-[blue]-[/cloudgate]
# tcpdump -tteni pflog0 &
[1] 31913
[0]-[blue]-[/cloudgate]
# tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
pfctl -e
pf enabled
[0]-[blue]-[/cloudgate]
# ping -c2 -w2 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 172.16.0.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 172.16.0.1 64 chars, ret=-1
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[1]-[blue-viking]-[/cloudgate]
# ifconfig gre
gre0: flags=9011<UP,POINTOPOINT,LINK0,MULTICAST> mtu 1476
description: citywan
priority: 0
keepalive: timeout 10 count 6
groups: gre
status: keepalive down
tunnel: inet 10.19.71.31 -> 10.54.213.241
inet 172.16.0.2 --> 172.16.0.1 netmask 0xffffffff
But i would like to match out on gre0 from (x:network) to !(self) nat-to
(gre0:0)
Not possible ?

Following up on the gre interface, the routing is odd, once gre is up i
got data form a side ,
yet no forwarding is done.
[0]-[villemarie]-[/root]
# tcpdump -tteni gre0 icmp
tcpdump: listening on gre0, link-type LOOP
1452800353.714927 172.16.0.2 > 8.8.8.8: icmp: echo request
1452800353.715047 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
1452800354.725152 172.16.0.2 > 8.8.8.8: icmp: echo request
1452800354.725240 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
1452800355.735124 172.16.0.2 > 8.8.8.8: icmp: echo request
1452800355.735213 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
^C
8 packets received by filter
0 packets dropped by kernel
[0]-[villemarie]-[/root]
# netstat -rnv -f inet | grep default
default 192.168.10.1 UGS 6 1510585 - 8
re0 DHCLIENT MANUAL
[0]-[villemarie]-[/root]
# tcpdump -tteni re0 icmp
tcpdump: listening on re0, link-type EN10MB
^C
46 packets received by filter
0 packets dropped by kernel
[0]-[villemarie]-[/root]
# sysctl -a | grep forwarding
net.inet.ip.forwarding=1
nothing is blocked in pf once againt aso the timing ot the reply is very
short.
I was expecting the data to be routed .

and it does, it feels like adding the route after the interface creation
got an effect.. but unsure.
First problem still unsolved.

Ok this morning the routing of gif was not done , after deleting the
default route and readding it,
tada, it s routed again.

I will test with 5.8 , is it enough or do you absolutely require current ?
i think for this case only the kernel could be updated.

Please take a look Test Log :

#validate the routing is broken

[1]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867126.675719 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.675899 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.785273 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.785371 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.895401 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.895552 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867127.005380 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867127.005474 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable

^C
8 packets received by filter
0 packets dropped by kernel

#But route is here, why replying unreachable ? (label is here because we
manage multiple default route )

[0]-[villemarie]-[/root]
# netstat -rnv | grep defa
default 192.168.10.1 UGS 115 684491 - 8 re0
DHCLIENT MINE

# ok lets try to confirm the yesterday strange behavior

[1]-[villemarie]-[/root]
# route delete default
delete net default
[0]-[villemarie]-[/root]
# route add default 192.168.10.1 -mpath -label "DHCLIENT GIF"
add net default: gateway 192.168.10.1
[0]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867248.839222 8.8.8.8 > 172.16.0.1: icmp: echo reply
1452867249.834122 172.16.0.1 > 8.8.8.8: icmp: echo request

# wow that s strange !

[sven falempin]

Post by sven falempin
Ok this morning the routing of gif was not done , after deleting the
default route and readding it,
tada, it s routed again.
I will test with 5.8 , is it enough or do you absolutely require current ?
i think for this case only the kernel could be updated.
#validate the routing is broken
[1]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867126.675719 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.675899 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.785273 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.785371 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.895401 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.895552 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867127.005380 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867127.005474 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
^C
8 packets received by filter
0 packets dropped by kernel
#But route is here, why replying unreachable ? (label is here because we
manage multiple default route )
[0]-[villemarie]-[/root]
# netstat -rnv | grep defa
default 192.168.10.1 UGS 115 684491 - 8
re0 DHCLIENT MINE
# ok lets try to confirm the yesterday strange behavior
[1]-[villemarie]-[/root]
# route delete default
delete net default
[0]-[villemarie]-[/root]
# route add default 192.168.10.1 -mpath -label "DHCLIENT GIF"
add net default: gateway 192.168.10.1
[0]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867248.839222 8.8.8.8 > 172.16.0.1: icmp: echo reply
1452867249.834122 172.16.0.1 > 8.8.8.8: icmp: echo request
# wow that s strange !

It s all 5.8 stable now.
gif is unstable.

[0]-[58-gif]-[~]
# ping 172.16.0.1
ping: wrote 172.16.0.1 64 chars, ret=-1
--- 172.16.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
[1]-[58-gif]-[~]
# ifconfig gif0 down
[0]-[58-gif]-[~]
# ifconfig gif0 up
[0]-[58-gif]-[~]
# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=1.122 ms

i now activate ifconfig gif0 debug

Something nasty in there.

[Stuart Henderson]

Post by sven falempin
I will test with 5.8 , is it enough or do you absolutely require current ?
i think for this case only the kernel could be updated.

There have been big changes to the network/routing stack since 5.8 - at
least two hackathons with significant focus on this area. Neither 5.8
nor 5.8-stable are enough.

It could be fixed already. Or it could have different behaviour. If not,
here is very little chance it will be fixed for 5.9 unless someone seeing
a problem gets in a good bug report on -current.

[Stuart Henderson]

Post by Stuart Henderson

Post by sven falempin
I will test with 5.8 , is it enough or do you absolutely require current ?
i think for this case only the kernel could be updated.

There have been big changes to the network/routing stack since 5.8 - at
least two hackathons with significant focus on this area. Neither 5.8
nor 5.8-stable are enough.
It could be fixed already. Or it could have different behaviour. If not,
here is very little chance it will be fixed for 5.9 unless someone seeing
a problem gets in a good bug report on -current.

P.S. Kernel *and* userland.