On Thu, Jan 14, 2016 at 8:56 PM, sven falempin <[email protected]> wrote:
> > > On Thu, Jan 14, 2016 at 3:14 PM, sven falempin <[email protected]> > wrote: > >> >> On Thu, Jan 14, 2016 at 1:08 PM, sven falempin <[email protected]> >> wrote: >> >>> 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 ! -- --------------------------------------------------------------------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\
