Re: inet6 packet filter question: link local address vs antispoof

2017-06-20 Thread Harald Dunkel
Hi Martin,

the host I had used for testing is off, so I had to switch. After
disabling the packet filter I see:

# tcpdump -i re0 -env icmp6
tcpdump: listening on re0, link-type EN10MB
20:58:08.865529 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:49) [flowlabel 0x32128] (len 64, hlim 64)
20:58:08.865643 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:49) (len 64, hlim 64)
20:58:09.889659 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:50) [flowlabel 0x32128] (len 64, hlim 64)
20:58:09.889738 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:50) (len 64, hlim 64)
20:58:10.913592 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:51) [flowlabel 0x32128] (len 64, hlim 64)
20:58:10.913704 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:51) (len 64, hlim 64)
20:58:11.864126 00:20:4e:6c:8c:3b 33:33:00:00:00:02 86dd 70: 
fe80::220:4eff:fe6c:8c3b > ff02::2: icmp6: router solicitation (src lladdr: 
00:20:4e:6c:8c:3b) [icmp6 cksum ok] (len 16, hlim 255)
20:58:11.937665 20:cf:30:e8:0d:58 52:54:00:2e:f3:25 86dd 118: 
fe80::22cf:30ff:fee8:d58 > fe80::5054:ff:fe2e:f325: icmp6: echo request 
(id:794e seq:52) [flowlabel 0x32128] (len 64, hlim 64)
20:58:11.937743 52:54:00:2e:f3:25 20:cf:30:e8:0d:58 86dd 118: ::1 > 
fe80::22cf:30ff:fee8:d58: icmp6: echo reply (id:794e seq:52) (len 64, hlim 64)
^C
161 packets received by filter
0 packets dropped by kernel
# route -n show -inet6
Routing tables

Internet6:
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
::/96  ::1UGRS   0  
  0 32768 8 lo0
::/104 ::1UGRS   0  
  0 32768 8 lo0
::1::1UHhl  14  
294 32768 1 lo0
::127.0.0.0/104::1UGRS   0  
  0 32768 8 lo0
::224.0.0.0/100::1UGRS   0  
  0 32768 8 lo0
::255.0.0.0/104::1UGRS   0  
  0 32768 8 lo0
:::0.0.0.0/96  ::1UGRS   0  
  0 32768 8 lo0
2002::/24  ::1UGRS   0  
  0 32768 8 lo0
2002:7f00::/24 ::1UGRS   0  
  0 32768 8 lo0
2002:e000::/20 ::1UGRS   0  
  0 32768 8 lo0
2002:ff00::/24 ::1UGRS   0  
  0 32768 8 lo0
fe80::/10  ::1UGRS   0  
424 32768 8 lo0
fec0::/10  ::1UGRS   0  
  0 32768 8 lo0
fe80::%re0/64  fe80::5054:ff:fe2e:f325%re0UCn2  
  2 - 4 re0
fe80::22cf:30ff:fee8:d58%re0   20:cf:30:e8:0d:58  UHLc   0  
 73 - 3 re0
fe80::5054:ff:fe2e:f325%re052:54:00:2e:f3:25  UHLl   0  
153 - 1 re0
fe80::56be:f7ff:fe09:30bd%re0  54:be:f7:09:30:bd  UHLc   0  
109 - 3 re0
fe80::1%lo0fe80::1%lo0UHl0  
  0 32768 1 lo0
ff01::/16  ::1UGRS   0  
  1 32768 8 lo0
ff01::%re0/32  fe80::5054:ff:fe2e:f325%re0Um 0  
  0 - 4 re0
ff01::%lo0/32  ::1Um 0  
  1 32768 4 lo0
ff02::/16  ::1UGRS   0  
  1 32768 8 lo0
ff02::%re0/32  fe80::5054:ff:fe2e:f325%re0Um 0  
  0 - 4 re0
ff02::%lo0/32  ::1Um 0  
  1 32768 4 lo0


Unfortunately I don't have a test host running 6.0 at the moment.


Regards

Harri



Re: inet6 packet filter question: link local address vs antispoof

2017-06-20 Thread Martin Pieuchot
On 11/06/17(Sun) 16:23, Harald Dunkel wrote:
> PS #1: Outgoing traffic to a link-local address initiated by the
> gateway is not corrupted.
> 
> PS #2: It seems that OpenBSD 6.0 doesn't show this problem.

Could you use tcpdump on 6.0, do you spot any difference?



Re: inet6 packet filter question: link local address vs antispoof

2017-06-20 Thread Martin Pieuchot
On 11/06/17(Sun) 15:51, Harald Dunkel wrote:
> Hi folks,
> 
> pf.conf on my gateway (6.1) says
> 
> bash-4.4# pfctl -sr | egrep -i icmp\|block
> block return log all
> :
> :
> pass quick inet proto icmp all keep state (if-bound)
> pass quick inet6 proto ipv6-icmp all keep state (if-bound)
> 
> Problem is, a ping6 to the gateway's link local address is not
> answered. The pflog file reveals
> 
> 15:11:35.491878 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:1) (len 64, hlim 64)
> 15:11:36.520792 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:2) (len 64, hlim 64)
> 15:11:37.544670 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:3) (len 64, hlim 64)
> 
> Please note the "::1". This address is not bound to re1. If I
> disable the firewall(!), or if I use
> 
>   pass quick inet6 proto ipv6-icmp all no state
> 
> then the icmp6 echo reply can pass:
> 
> bash-4.4# tcpdump -i re1 -env icmp6
> tcpdump: listening on re1, link-type EN10MB
> 15:13:36.328563 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:30) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:36.328689 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:30) (len 64, hlim 64)
> 15:13:37.352729 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:31) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:37.352845 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:31) (len 64, hlim 64)
> 15:13:38.376557 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:32) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:38.376672 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:32) (len 64, hlim 64)
> 15:13:39.400577 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:33) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:39.400693 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:33) (len 64, hlim 64)
> 
> But this doesn't help. The sender address of the echo reply is still
> bad. It is blocked by some antispoof rule on the receiver, afaict.

Looks like the source address selection for the reply is wrong.  Could
you please show me the routing table of this machine?

$ route -n show -inet6



inet6 packet filter question: link local address vs antispoof

2017-06-11 Thread Harald Dunkel
Hi folks,

pf.conf on my gateway (6.1) says

bash-4.4# pfctl -sr | egrep -i icmp\|block
block return log all
:
:
pass quick inet proto icmp all keep state (if-bound)
pass quick inet6 proto ipv6-icmp all keep state (if-bound)

Problem is, a ping6 to the gateway's link local address is not
answered. The pflog file reveals

15:11:35.491878 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
(id:7445 seq:1) (len 64, hlim 64)
15:11:36.520792 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
(id:7445 seq:2) (len 64, hlim 64)
15:11:37.544670 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
(id:7445 seq:3) (len 64, hlim 64)

Please note the "::1". This address is not bound to re1. If I
disable the firewall(!), or if I use

pass quick inet6 proto ipv6-icmp all no state

then the icmp6 echo reply can pass:

bash-4.4# tcpdump -i re1 -env icmp6
tcpdump: listening on re1, link-type EN10MB
15:13:36.328563 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
(id:74c1 seq:30) [flowlabel 0x47412] (len 64, hlim 255)
15:13:36.328689 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:30) (len 64, hlim 64)
15:13:37.352729 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
(id:74c1 seq:31) [flowlabel 0x47412] (len 64, hlim 255)
15:13:37.352845 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:31) (len 64, hlim 64)
15:13:38.376557 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
(id:74c1 seq:32) [flowlabel 0x47412] (len 64, hlim 255)
15:13:38.376672 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:32) (len 64, hlim 64)
15:13:39.400577 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
(id:74c1 seq:33) [flowlabel 0x47412] (len 64, hlim 255)
15:13:39.400693 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:33) (len 64, hlim 64)

But this doesn't help. The sender address of the echo reply is still
bad. It is blocked by some antispoof rule on the receiver, afaict.

Is there some secret sysctl I missed to adjust?


Every helpful comment is highly appreciated.
Harri



Re: inet6 packet filter question: link local address vs antispoof

2017-06-11 Thread Harald Dunkel
PS #1: Outgoing traffic to a link-local address initiated by the
gateway is not corrupted.

PS #2: It seems that OpenBSD 6.0 doesn't show this problem.

Regards
Harri