pf and arp problem

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

pf and arp problem

Miguel Miranda
Hi, im having serious problems with (i think) arp protocol, my openbsd
firewall always tries to resolve the arp address, look at this:


# ping 200.13.161.2
PING 200.13.161.2 (200.13.161.2): 56 data bytes
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
64 bytes from 200.13.161.2: icmp_seq=7 ttl=255 time=0.684 ms
64 bytes from 200.13.161.2: icmp_seq=8 ttl=255 time=0.306 ms
64 bytes from 200.13.161.2: icmp_seq=9 ttl=255 time=0.494 ms
64 bytes from 200.13.161.2: icmp_seq=10 ttl=255 time=0.381 ms
--- 200.13.161.2 ping statistics ---
11 packets transmitted, 4 packets received, 63.6% packet loss
round-trip min/avg/max/std-dev = 0.306/0.466/0.684/0.143 ms
# ping 200.13.161.2
PING 200.13.161.2 (200.13.161.2): 56 data bytes
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.2 64 chars, ret=-1
64 bytes from 200.13.161.2: icmp_seq=4 ttl=255 time=0.717 ms
64 bytes from 200.13.161.2: icmp_seq=5 ttl=255 time=0.478 ms
64 bytes from 200.13.161.2: icmp_seq=6 ttl=255 time=0.512 ms
--- 200.13.161.2 ping statistics ---
7 packets transmitted, 3 packets received, 57.1% packet loss
round-trip min/avg/max/std-dev = 0.478/0.569/0.717/0.105 ms


first,  i get No route to host, after a few seconds i got response, a
few second later a try again and the same No route to host problem.
any advise?

BTW , im running openbsd 3.8 on sun netra v120
thanks

Reply | Threaded
Open this post in threaded view
|

Re: pf and arp problem

Joachim Schipper
On Tue, Jan 31, 2006 at 09:48:13AM -0600, Miguel wrote:

> Hi, im having serious problems with (i think) arp protocol, my openbsd
> firewall always tries to resolve the arp address, look at this:
>
>
> # ping 200.13.161.2
> PING 200.13.161.2 (200.13.161.2): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> 64 bytes from 200.13.161.2: icmp_seq=7 ttl=255 time=0.684 ms
> 64 bytes from 200.13.161.2: icmp_seq=8 ttl=255 time=0.306 ms
> 64 bytes from 200.13.161.2: icmp_seq=9 ttl=255 time=0.494 ms
> 64 bytes from 200.13.161.2: icmp_seq=10 ttl=255 time=0.381 ms
> --- 200.13.161.2 ping statistics ---
> 11 packets transmitted, 4 packets received, 63.6% packet loss
> round-trip min/avg/max/std-dev = 0.306/0.466/0.684/0.143 ms
> # ping 200.13.161.2
> PING 200.13.161.2 (200.13.161.2): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.2 64 chars, ret=-1
> 64 bytes from 200.13.161.2: icmp_seq=4 ttl=255 time=0.717 ms
> 64 bytes from 200.13.161.2: icmp_seq=5 ttl=255 time=0.478 ms
> 64 bytes from 200.13.161.2: icmp_seq=6 ttl=255 time=0.512 ms
> --- 200.13.161.2 ping statistics ---
> 7 packets transmitted, 3 packets received, 57.1% packet loss
> round-trip min/avg/max/std-dev = 0.478/0.569/0.717/0.105 ms
>
>
> first,  i get No route to host, after a few seconds i got response, a
> few second later a try again and the same No route to host problem.
> any advise?

There's an arp(8) command you can use to check your suspicions.
Otherwise, I'd like a packet trace - any chance of running tcpdump
-nvvvXs 65535 host 200.13.161.2 while doing the above?

(Though I'm not certain you are right about arp being the problem - if
it was, why'd the second ping have the same problem? Arp is cached.)

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: pf and arp problem

Miguel Miranda
Joachim Schipper wrote:

>There's an arp(8) command you can use to check your suspicions.
>Otherwise, I'd like a packet trace - any chance of running tcpdump
>-nvvvXs 65535 host 200.13.161.2 while doing the above?
>
>(Though I'm not certain you are right about arp being the problem - if
>it was, why'd the second ping have the same problem? Arp is cached.)
>
> Joachim
>
>
>  
>



You are right, this is even worst :


# ping 200.13.161.3
PING 200.13.161.3 (200.13.161.3): 56 data bytes
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
64 bytes from 200.13.161.3: icmp_seq=4 ttl=255 time=0.592 ms
64 bytes from 200.13.161.3: icmp_seq=5 ttl=255 time=0.302 ms
64 bytes from 200.13.161.3: icmp_seq=6 ttl=255 time=0.365 ms
64 bytes from 200.13.161.3: icmp_seq=7 ttl=255 time=0.357 ms
--- 200.13.161.3 ping statistics ---
8 packets transmitted, 4 packets received, 50.0% packet loss
round-trip min/avg/max/std-dev = 0.302/0.404/0.592/0.111 ms
# arp -a
? (200.13.161.2) at 00:03:ba:04:cd:02 on hme0
? (200.13.161.3) at 00:03:ba:05:01:2c on hme0
? (200.13.161.6) at 00:12:79:d4:95:63 on hme0
# ping 200.13.161.3
PING 200.13.161.3 (200.13.161.3): 56 data bytes
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 200.13.161.3 64 chars, ret=-1
64 bytes from 200.13.161.3: icmp_seq=3 ttl=255 time=0.476 ms
64 bytes from 200.13.161.3: icmp_seq=4 ttl=255 time=0.306 ms
--- 200.13.161.3 ping statistics ---
5 packets transmitted, 2 packets received, 60.0% packet loss
round-trip min/avg/max/std-dev = 0.306/0.391/0.476/0.085 ms
#

the arp entry is cached, but the No route to host is always there.
BTW, i tried the packet trace but its a lot of output, it is my dns
server, so i cant read the output, look at an example


10:26:01.443020 200.13.190.132.1075 > 200.13.161.2.53:  [udp sum ok]
5054+ A? hp.msn.com. (28) (ttl 126, id 46030, len 56)
  0000: 4500 0038 b3ce 0000 7e11 9944 c80d be84  E..83N..~..DH.>.
  0010: c80d a102 0433 0035 0024 d888 13be 0100  H.!..3.5.$X..>..
  0020: 0001 0000 0000 0000 0268 7003 6d73 6e03  .........hp.msn.
  0030: 636f 6d00 0001 0001 449d 8a02            com.....D...

10:26:01.443614 200.13.161.2.53 > 217.16.26.177.53:  [udp sum ok] 41273%
[1au] A6? ns2.madgroup.ru. ar: . OPT UDPsize=2048 (44) (DF) (ttl 254, id
31947, len 72)
  0000: 4500 0048 7ccb 4000 fe11 a307 c80d a102  E..H|K@.~.#.H.!.
  0010: d910 1ab1 0035 0035 0034 b803 a139 0010  Y..1.5.5.48.!9..
  0020: 0001 0000 0000 0001 036e 7332 086d 6164  .........ns2.mad
  0030: 6772 6f75 7002 7275 0000 2600 0100 0029  group.ru..&....)
  0040: 0800 0000 8000 0000                      ........

10:26:01.444526 200.13.161.2.53 > 200.13.190.132.1075:  [udp sum ok]
5054 q: A? hp.msn.com. 3/3/1 hp.msn.com. CNAME
hm.sc.msn.com.c.footprint.net., hm.sc.msn.com.c.footprint.net. A
66.77.84.94, hm.sc.msn.com.c.footprint.net. A 67.72.8.94 ns:
c.footprint.net. NS b.ns.c.footprint.net., c.footprint.net. NS
us-mi-1.ns.c.footprint.net., c.footprint.net. NS a.ns.c.footprint.net.
ar: us-mi-1.ns.c.footprint.net. A 166.90.248.209 (176) (DF) (ttl 254, id
18984, len 204)
  0000: 4500 00cc 4a28 4000 fe11 4256 c80d a102  E..LJ(@.~.BVH.!.
  0010: c80d be84 0035 0433 00b8 f050 13be 8180  H.>..5.3.8pP.>..
  0020: 0001 0003 0003 0001 0268 7003 6d73 6e03  .........hp.msn.
  0030: 636f 6d00 0001 0001 c00c 0005 0001 0000  com.....@.......
  0040: 0308 001f 0268 6d02 7363 036d 736e 0363  .....hm.sc.msn.c
  0050: 6f6d 0163 0966 6f6f 7470 7269 6e74 036e  om.c.footprint.n
  0060: 6574 00c0 2800 0100 0100 0000 8500 0442  et.@(..........B
  0070: 4d54 5ec0 2800 0100 0100 0000 8500 0443  MT^@(..........C
  0080: 4808 5ec0 3600 0200 0100 0151 5500 0701  H.^@6......QU...
  0090: 6202 6e73 c036 c036 0002 0001 0001 5155  b.ns@6@6......QU
  00a0: 000a 0775 732d 6d69 2d31 c075 c036 0002  ...us-mi-1@u@6..
  00b0: 0001 0001 5155 0004 0161 c075 c086 0001  ....QU...a@u@...
  00c0: 0001 0002 a2d5 0004 a65a f8d1            ...."U..&ZxQ

10:26:01.454125 200.13.173.241.28479 > 200.13.161.2.53:  [udp sum ok]
12685+ A? Irc.Real.H4ck.Biz. (35) (ttl 125, id 50535, len 63)
  0000: 4500 003f c567 0000 7d11 9937 c80d adf1  E..?Eg..}..7H.-q
  0010: c80d a102 6f3f 0035 002b 18c6 318d 0100  H.!.o?.5.+.F1...
  0020: 0001 0000 0000 0000 0349 7263 0452 6561  .........Irc.Rea
  0030: 6c04 4834 636b 0342 697a 0000 0100 0174  l.H4ck.Biz.....t
  0040: a1e2 53                                  !bS

10:26:01.478620 200.13.181.18.1047 > 200.13.161.2.53:  [udp sum ok]
39484+ A? t.msn.com. (27) (ttl 124, id 1382, len 55)
  0000: 4500 0037 0566 0000 7c11 5320 c80d b512  E..7.f..|.S H.5.
  0010: c80d a102 0417 0035 0023 8cce 9a3c 0100  H.!....5.#.N.<..
  0020: 0001 0000 0000 0000 0174 036d 736e 0363  .........t.msn.c
  0030: 6f6d 0000 0100 017d 5943 6e              om.....}YCn

^C
39448 packets received by filter
273 packets dropped by kernel

Reply | Threaded
Open this post in threaded view
|

Re: pf and arp problem

Joachim Schipper
On Tue, Jan 31, 2006 at 10:32:14AM -0600, Miguel wrote:

> Joachim Schipper wrote:
>
> >There's an arp(8) command you can use to check your suspicions.
> >Otherwise, I'd like a packet trace - any chance of running tcpdump
> >-nvvvXs 65535 host 200.13.161.2 while doing the above?
> >
> >(Though I'm not certain you are right about arp being the problem - if
> >it was, why'd the second ping have the same problem? Arp is cached.)
>
> You are right, this is even worst :
>
>
> # ping 200.13.161.3
> PING 200.13.161.3 (200.13.161.3): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> 64 bytes from 200.13.161.3: icmp_seq=4 ttl=255 time=0.592 ms
> 64 bytes from 200.13.161.3: icmp_seq=5 ttl=255 time=0.302 ms
> 64 bytes from 200.13.161.3: icmp_seq=6 ttl=255 time=0.365 ms
> 64 bytes from 200.13.161.3: icmp_seq=7 ttl=255 time=0.357 ms
> --- 200.13.161.3 ping statistics ---
> 8 packets transmitted, 4 packets received, 50.0% packet loss
> round-trip min/avg/max/std-dev = 0.302/0.404/0.592/0.111 ms
> # arp -a
> ? (200.13.161.2) at 00:03:ba:04:cd:02 on hme0
> ? (200.13.161.3) at 00:03:ba:05:01:2c on hme0
> ? (200.13.161.6) at 00:12:79:d4:95:63 on hme0

Looks fine, arp -a looks like this here:

calliope.jschipper.dynalias.net (192.168.14.1) at 00:30:4f:21:1f:81 on rl0

So that should work.

> # ping 200.13.161.3
> PING 200.13.161.3 (200.13.161.3): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 200.13.161.3 64 chars, ret=-1
> 64 bytes from 200.13.161.3: icmp_seq=3 ttl=255 time=0.476 ms
> 64 bytes from 200.13.161.3: icmp_seq=4 ttl=255 time=0.306 ms
> --- 200.13.161.3 ping statistics ---
> 5 packets transmitted, 2 packets received, 60.0% packet loss
> round-trip min/avg/max/std-dev = 0.306/0.391/0.476/0.085 ms
> #
>
> the arp entry is cached, but the No route to host is always there.
> BTW, i tried the packet trace but its a lot of output, it is my dns
> server, so i cant read the output, look at an example
<snip: mucho traffic>

That is, indeed, only dns traffic. Try tcpdump -s 65535 -w outfile
host 200.13.161.2 and ! port 53, followed by tcpdump -nvvvXs 65535 -r
outfile | less; this combination will allow you to read at your
convenience. Please note that it is possible to restrict the traffic
further in the read command, though it is obviously more efficient to
only write what you need.

                Joachim