Just to follow up to myself here - I am more and more convinced this is me screwing up my rules some how. I just can't see where I am making the mistake.
Here is what I did: on the tun interface: 18:28:54.271507 10.255.253.37.49359 > 10.10.80.116.135: S 1541251005:1541251005(0) win 8192 <mss 1160,nop,wscale 8,nop,nop,sackOK> (DF) 18:28:54.271887 10.10.80.116.135 > 10.255.253.37.49359: S 2255202639:2255202639(0) ack 1541251006 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:28:54.331237 10.255.253.37.49359 > 10.10.80.116.135: . ack 1 win 67 (DF) 18:28:54.333947 10.255.253.37.49359 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:28:54.766731 10.255.253.37.49359 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:28:54.766964 10.10.80.116.135 > 10.255.253.37.49359: . ack 117 win 65419 (DF) 18:29:44.383503 10.255.253.37.49359 > 10.10.80.116.135: R 117:117(0) ack 1 win 0 (DF) on the lan interface: 18:28:54.271663 10.255.253.37.49359 > 10.10.80.116.135: S 1541251005:1541251005(0) win 8192 <mss 1160,nop,wscale 8,nop,nop,sackOK> (DF) 18:28:54.271776 10.10.80.116.135 > 10.255.253.37.49359: S 2255202639:2255202639(0) ack 1541251006 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:28:54.331285 10.255.253.37.49359 > 10.10.80.116.135: . ack 1 win 67 (DF) 18:28:54.334002 10.255.253.37.49359 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:28:54.334194 10.10.80.116.135 > 10.255.253.37.49359: P 1:85(84) ack 117 win 65419 (DF) 18:28:54.766821 10.255.253.37.49359 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:28:54.766917 10.10.80.116.135 > 10.255.253.37.49359: . ack 117 win 65419 (DF) 18:28:57.387869 10.10.80.116.135 > 10.255.253.37.49359: P 1:85(84) ack 117 win 65419 (DF) 18:29:03.403532 10.10.80.116.135 > 10.255.253.37.49359: P 1:85(84) ack 117 win 65419 (DF) 18:29:15.434839 10.10.80.116.135 > 10.255.253.37.49359: P 1:85(84) ack 117 win 65419 (DF) 18:29:39.497462 10.10.80.116.135 > 10.255.253.37.49359: P 1:85(84) ack 117 win 65419 (DF) 18:29:44.383561 10.255.253.37.49359 > 10.10.80.116.135: R 117:117(0) ack 1 win 0 (DF) And then altering rules, I changed them slightly to: pass quick log on tun2 proto udp from 10.10.80.0/24 port 135 to 10.255.253.0/24 keep state pass quick log on tun2 proto tcp from 10.10.80.0/24 port 135 to 10.255.253.0/24 flags S/SA keep state #pass quick on tun2 from 10.255.253.0/24 to any flags S/SA keep state label "UserVPNAdmin" pass quick log (all) on tun2 from 10.255.253.0/24 to any flags S/SA keep state label "UserVPNAdmin" #pass quick on tun2 from 10.255.253.0/24 to any keep state label "UserVPNAdmin" pass quick log on fxp0 from 10.10.80.0/24 to 10.255.253.0/24 flags S/SA keep state label "UserVPNAdmin" #pass quick on fxp0 from 10.10.80.0/24 to 10.255.253.0/24 keep state label "UserVPNAdmin" In a effort to get a better view into what is going on by increasing the amount of logs I am grabbing. (I do understand it is considered bad form to not post the entire pf.conf. In this case I am not doing it as I have a rather lengthy rules set covering six interfaces and I do not want to confuse the situation with the noise the entire rules set would present. I am using all quick rules here as you can see, and I have these placed at the top of the rule set to prevent any other rules from getting in the mix. If anyone wants to see the entire rule set, I would be happy to mail it directly as long as you know what you will be getting.) With the rule changes I was able to pick up: Jan 03 18:28:54.271550 rule 29/(match) pass in on tun2: 10.255.253.37.49359> 10.10.80.116.135: [|tcp] (DF) Jan 03 18:28:54.271883 rule 29/(match) pass out on tun2: 10.10.80.116.135 > 10.255.253.37.49359: [|tcp] Jan 03 18:28:54.331255 rule 29/(match) pass in on tun2: 10.255.253.37.49359> 10.10.80.116.135: [|tcp] (DF) Jan 03 18:28:54.333963 rule 29/(match) pass in on tun2: 10.255.253.37.49359> 10.10.80.116.135: [|tcp] (DF) Jan 03 18:28:54.766770 rule 29/(match) pass in on tun2: 10.255.253.37.49359> 10.10.80.116.135: [|tcp] (DF) Jan 03 18:28:54.766960 rule 29/(match) pass out on tun2: 10.10.80.116.135 > 10.255.253.37.49359: [|tcp] (DF) Jan 03 18:29:16.653047 rule 29/(match) pass in on tun2: 10.255.253.37.49360> 10.10.80.61.139: [|tcp] (DF) Jan 03 18:29:16.653355 rule 29/(match) pass out on tun2: 10.10.80.61.139 > 10.255.253.37.49360: [|tcp] Jan 03 18:29:16.707484 rule 29/(match) pass in on tun2: 10.255.253.37.49360> 10.10.80.61.139: [|tcp] (DF) Jan 03 18:29:16.707677 rule 29/(match) pass out on tun2: 10.10.80.61.139 > 10.255.253.37.49360: [|tcp] (DF) Jan 03 18:29:16.765388 rule 29/(match) pass in on tun2: 10.255.253.37.49360> 10.10.80.61.139: [|tcp] (DF) Jan 03 18:29:17.822411 rule 29/(match) pass in on tun2: 10.255.253.37.49360> 10.10.80.61.139: [|tcp] (DF) Jan 03 18:29:17.822607 rule 29/(match) pass out on tun2: 10.10.80.61.139 > 10.255.253.37.49360: [|tcp] (DF) Jan 03 18:29:44.383525 rule 29/(match) pass in on tun2: 10.255.253.37.49359> 10.10.80.116.135: [|tcp] (DF) The way I am reading this, packets are coming in my inside interface that are not matching the state rule. Nothing is getting blocked at all either, as that would be logged and show up. However after the inital handshake there should be one .253, one .116 and one .253. In the logs however I am not seeing the packet from .116 on the pf logs. As well, no other rule is picking up the packet as part of separate state. Any suggestions on what I am screwing up here? To make it a touch more complex, other apps work just fine. From the tun interface: 18:57:59.085767 10.255.253.37.49481 > 10.10.80.116.443: S 1885782376:1885782376(0) win 8192 <mss 1160,nop,wscale 2,nop,nop,sackOK> (DF) 18:57:59.086068 10.10.80.116.443 > 10.255.253.37.49481: S 2765933002:2765933002(0) ack 1885782377 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:57:59.139817 10.255.253.37.49481 > 10.10.80.116.443: . ack 1 win 4350 (DF) 18:58:00.291898 10.255.253.37.49481 > 10.10.80.116.443: P 1:102(101) ack 1 win 4350 (DF) 18:58:00.292344 10.10.80.116.443 > 10.255.253.37.49481: P 1:983(982) ack 102 win 65434 (DF) 18:58:00.360867 10.255.253.37.49481 > 10.10.80.116.443: P 102:284(182) ack 983 win 4104 (DF) 18:58:00.363744 10.10.80.116.443 > 10.255.253.37.49481: P 983:1026(43) ack 284 win 65252 (DF) 18:58:00.699697 10.255.253.37.49481 > 10.10.80.116.443: . ack 1026 win 4093 (DF) 18:58:01.030022 10.255.253.37.49481 > 10.10.80.116.443: F 284:284(0) ack 1026 win 4093 (DF) No issues at all. Also, other clients can use this same application with no problems at all. At first I was convinced this problem was on the client side. But looking at these traces make me sure that the problem is on the firewall. I just don't understand why this would work for some clients and others it would have problems. Thanks Jim On 1/3/07, Jim O'Gorman <[EMAIL PROTECTED]> wrote: > > I am having a issue that I am having some issues tracking down, and could > use a good shove in the right direction. > > On OBSD 3.9 with PF and OpenVPN 2.0.5 I am getting some odd traffic. > > OpenVPN runs over a tun interface, tcpdump is showing me: > > 11:33:41.980730 10.255.253.37.49664 > 10.10.80.116.135: S > 4140027697:4140027697(0) win 8192 <mss 1368,nop,wscale 8,nop,nop,sackOK> > (DF) > 11:33:41.981055 10.10.80.116.135 > 10.255.253.37.49664: S > 3483761931:3483761931(0) ack 4140027698 win 16384 <mss 1460,nop,wscale > 0,nop,nop,sackOK> > 11:33:42.042679 10.255.253.37.49664 > 10.10.80.116.135: . ack 1 win 64 > (DF) > 11:33:42.044939 10.255.253.37.49664 > 10.10.80.116.135: P 1:117(116) ack 1 > win 64 (DF) > 11:33:43.013161 10.255.253.37.49664 > 10.10.80.116.135 : P 1:117(116) ack > 1 win 64 (DF) > 11:33:43.013348 10.10.80.116.135 > 10.255.253.37.49664: . ack 117 win > 65419 (DF) > 11:34:31.698092 10.255.253.37.49664 > 10.10.80.116.135: R 117:117(0) ack 1 > win 0 (DF) > > On the lan interface I am getting > 11:33:41.980861 10.255.253.37.49664 > 10.10.80.116.135: S > 4140027697:4140027697(0) win 8192 <mss 1368,nop,wscale 8,nop,nop,sackOK> > (DF) > 11:33:41.980960 10.10.80.116.135 > 10.255.253.37.49664: S > 3483761931:3483761931(0) ack 4140027698 win 16384 <mss 1460,nop,wscale > 0,nop,nop,sackOK> > 11:33:42.042730 10.255.253.37.49664 > 10.10.80.116.135: . ack 1 win 64 > (DF) > 11:33:42.044971 10.255.253.37.49664 > 10.10.80.116.135: P 1:117(116) ack 1 > win 64 (DF) > 11:33:42.045104 10.10.80.116.135 > 10.255.253.37.49664 : P 1:85(84) ack > 117 win 65419 (DF) > 11:33:43.013210 10.255.253.37.49664 > 10.10.80.116.135: P 1:117(116) ack 1 > win 64 (DF) > 11:33:43.013310 10.10.80.116.135 > 10.255.253.37.49664: . ack 117 win > 65419 (DF) > 11:33: 44.935524 10.10.80.116.135 > 10.255.253.37.49664: P 1:85(84) ack > 117 win 65419 (DF) > 11:33:50.951203 10.10.80.116.135 > 10.255.253.37.49664: P 1:85(84) ack 117 > win 65419 (DF) > 11:34:02.982517 10.10.80.116.135 > 10.255.253.37.49664: P 1:85(84) ack 117 > win 65419 (DF) > 11:34:26.935788 10.10.80.116.135 > 10.255.253.37.49664: P 1:85(84) ack 117 > win 65419 (DF) > 11:34:31.698176 10.255.253.37.49664 > 10.10.80.116.135: R 117:117(0) ack 1 > win 0 (DF) > > On this, it appears to me that 10.10.80.116 can send an ack for 117 as > long as the packet has no other data is included along with the packet. when > 10.10.80.116 tries to push up data to 10.255.253.37, the packet never goes > across the tun interface. > > This pattern repeats on a regular basis. > > As for the relevant pf rules: > > pass quick on tun2 from 10.255.253.0/24 to any flags S/SA keep state label > "UserVPNAdmin" > pass quick on fxp0 from 10.10.80.0/24 to 10.255.253.0/24 flags S/SA keep > state label "UserVPNAdmin" > > Is at the top of the filter rules. > > I have googled around for this and tweaked a few settings here and there > but can't get any change in this behaviour. > > Anyone have any suggestions on where I should spend time looking for a > fix? > > Thanks > Jim > -- Jim [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.elwood.net
