Hello,
you are totally right ! I haven't thought about layer 2 problems.
But the problem is partially resolve, i have strange things with DF.
Port 80 is no-df but not port 411 (avaya cfg).
Here is a fragment of my pf config:
set skip on lo
set block-policy drop
set limit { states 100000, src-nodes 80000, table-entries 600000 }
match in scrub (no-df)
block in log all
pass out all
<...>
pass in quick inet from <toip_area_v4> to <toip_area_v4> scrub (no-df)
no state
Is something wrong ?
--
Best regards,
Loïc BLOT,
UNIX systems, security and network expert
http://www.unix-experience.fr
Le mercredi 25 septembre 2013 à 14:23 +0200, Mike Belopuhov a écrit :
> On 25 September 2013He 11:03, Loïc BLOT <loic.b...@unix-experience.fr> wrote:
> > Hello all,
> > i have searched many options but i haven't any new idea.
> >
> > I have 4 openbsd routers (2 on each site). Each router create a GRE
> > tunnel with it's pair.
> >
> > Here is the configuration:
> >
> > | S1R1 --- gre + ospf --- S2R1 |
> > LAN S1 (OSPF & RIP) | | LAN S2 (OSPF & RIP)
> > | S1R2 --- gre + ospf --- S2R2 |
> >
> > The routing rules are correct, ssh, http(s), smtp, ntp, ldap and many
> > other protocols works as expected between the two sites.
> >
> > But i have a problem with my Avaya phones on S2 which need to contact
> > the S1 gatekeeper. Some packets are lost, and (by sniffing every
> > interface) i don't found where the packets goes.
> >
> > If i capture LAN S1 link, i have this capture:
> >
> > 10:06:24.003479 192.168.238.121.56641 > 192.168.106.38.411: S
> > 2621611805:2621611805(0) win 5840 <mss 1460,sackOK,timestamp 4294948803
> > 0,nop,wscale 4> (DF)
> > 10:06:24.003607 192.168.106.38.411 > 192.168.238.121.56641: S
> > 3090220105:3090220105(0) ack 2621611806 win 5840 <mss 1460,nop,wscale 7>
> > (DF)
> > 10:06:24.018842 192.168.238.121.56641 > 192.168.106.38.411: . ack 1 win
> > 365 (DF)
> > 10:06:24.023582 192.168.238.121.56641 > 192.168.106.38.411: P 1:74(73)
> > ack 1 win 365 (DF)
> > 10:06:24.023710 192.168.106.38.411 > 192.168.238.121.56641: . ack 74 win
> > 46 (DF)
> > 10:06:24.024086 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1:1461(1460) ack 74 win 46 (DF)
> > 10:06:24.024329 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1461:2921(1460) ack 74 win 46 (DF)
> > 10:06:27.017704 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1:1461(1460) ack 74 win 46 (DF)
> > 10:06:33.017772 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1:1461(1460) ack 74 win 46 (DF)
> > 10:06:45.017907 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1:1461(1460) ack 74 win 46 (DF)
> > 10:07:09.018198 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1:1461(1460) ack 74 win 46 (DF)
> > 10:07:57.018732 192.168.106.38.411 > 192.168.238.121.56641: .
> > 1:1461(1460) ack 74 win 46 (DF)
> > 10:08:24.019074 192.168.106.38.411 > 192.168.238.121.56641: FP
> > 2921:4273(1352) ack 74 win 46 (DF)
> > 10:08:24.034803 192.168.238.121.56641 > 192.168.106.38.411: . ack 1 win
> > 365 (DF)
> >
> > If i capture the GRE tunnel i have this capture:
> >
> > 10:06:23.987975 192.168.238.121.56641 > 192.168.106.38.411: S
> > 2621611805:2621611805(0) win 5840 <mss 1460,sackOK,timestamp 4294948803
> > 0,nop,wscale 4> (DF)
> > 10:06:24.003614 192.168.106.38.411 > 192.168.238.121.56641: S
> > 3090220105:3090220105(0) ack 2621611806 win 5840 <mss 1460,nop,wscale 7>
> > (DF)
> > 10:06:24.018833 192.168.238.121.56641 > 192.168.106.38.411: . ack 1 win
> > 365 (DF)
> > 10:06:24.023573 192.168.238.121.56641 > 192.168.106.38.411: P 1:74(73)
> > ack 1 win 365 (DF)
> > 10:06:24.023716 192.168.106.38.411 > 192.168.238.121.56641: . ack 74 win
> > 46 (DF)
> > 10:08:24.019083 192.168.106.38.411 > 192.168.238.121.56641: FP
> > 2921:4273(1352) ack 74 win 46 (DF)
> > 10:08:24.034793 192.168.238.121.56641 > 192.168.106.38.411: . ack 1 win
> > 365 (DF)
> >
> > A part of the TCP transaction disappear and i don't know why.
> > Have you got ideas ???
> >
>
> this looks like a classical mtu problem. gre tunnel lowers the mtu
> and your tcp traffic uses mss of 1460 bytes and sets DF. therefore
> it gets dropped once the router figures out it can't send that much
> data over the gre link.
>
> possible solutions are using path mtu discovery on clients or making
> sure their mtu is less than 1500 or doing forced fragmentation and
> defragmentation on the router or configuring the application to use
> smaller mss value (setsockopt TCP_MAXSEG).
