In troubleshooting this, I updated the system to OBSD 4.0 and OVPN 2.0.9. Same situation, here is the LAN interface:
18:10:49.475930 10.255.253.37.49342 > 10.10.80.116.135: S 2103918215:2103918215(0) win 8192 <mss 1160,nop,wscale 8,nop,nop,sackOK> (DF) 18:10:49.476030 10.10.80.116.135 > 10.255.253.37.49342: S 1593573128:1593573128(0) ack 2103918216 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:10:49.546359 10.255.253.37.49342 > 10.10.80.116.135: . ack 1 win 67 (DF) 18:10:49.550593 10.255.253.37.49342 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:10:49.550723 10.10.80.116.135 > 10.255.253.37.49342: P 1:85(84) ack 117 win 65419 (DF) 18:10:50.319137 10.255.253.37.49342 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:10:50.319237 10.10.80.116.135 > 10.255.253.37.49342: . ack 117 win 65419 (DF) 18:10:52.487681 10.10.80.116.135 > 10.255.253.37.49342: P 1:85(84) ack 117 win 65419 (DF) 18:10:58.503257 10.10.80.116.135 > 10.255.253.37.49342: P 1:85(84) ack 117 win 65419 (DF) 18:11:10.534396 10.10.80.116.135 > 10.255.253.37.49342: P 1:85(84) ack 117 win 65419 (DF) 18:11:12.991800 10.255.253.37 > 10.10.80.116: icmp: echo request 18:11:12.991895 10.10.80.116 > 10.255.253.37: icmp: echo reply 18:11:13.048275 10.255.253.37.49331 > 10.10.80.116.389: P 351:363(12) ack 1 win 67 (DF) 18:11:13.159351 10.10.80.116.389 > 10.255.253.37.49331: . ack 363 win 65173 (DF) 18:11:13.217937 10.255.253.37.49331 > 10.10.80.116.389: P 363:713(350) ack 1 win 67 (DF) 18:11:13.378099 10.10.80.116.389 > 10.255.253.37.49331: . ack 713 win 64823 (DF) 18:11:34.487281 10.10.80.116.135 > 10.255.253.37.49342: P 1:85(84) ack 117 win 65419 (DF) 18:11:39.980001 10.255.253.37.49342 > 10.10.80.116.135: R 117:117(0) ack 1 win 0 (DF) 18:11:39.985180 10.255.253.37.49346 > 10.10.80.116.135: S 1542858070:1542858070(0) win 8192 <mss 1160,nop,wscale 8,nop,nop,sackOK> (DF) 18:11:39.985261 10.10.80.116.135 > 10.255.253.37.49346: S 2787720298:2787720298(0) ack 1542858071 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:11:40.039665 10.255.253.37.49346 > 10.10.80.116.135: . ack 1 win 67 (DF) 18:11:40.042081 10.255.253.37.49346 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:11:40.042203 10.10.80.116.135 > 10.255.253.37.49346: P 1:85(84) ack 117 win 65419 (DF) 18:11:41.114462 10.255.253.37.49346 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:11:41.114563 10.10.80.116.135 > 10.255.253.37.49346: . ack 117 win 65419 (DF) 18:11:42.909082 10.10.80.116.135 > 10.255.253.37.49346: P 1:85(84) ack 117 win 65419 (DF) And the Tun Interface: 18:10:49.475799 10.255.253.37.49342 > 10.10.80.116.135: S 2103918215:2103918215(0) win 8192 <mss 1160,nop,wscale 8,nop,nop,sackOK> (DF) 18:10:49.476136 10.10.80.116.135 > 10.255.253.37.49342: S 1593573128:1593573128(0) ack 2103918216 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:10:49.546281 10.255.253.37.49342 > 10.10.80.116.135: . ack 1 win 67 (DF) 18:10:49.550558 10.255.253.37.49342 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:10:50.319071 10.255.253.37.49342 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:10:50.319277 10.10.80.116.135 > 10.255.253.37.49342: . ack 117 win 65419 (DF) 18:11:12.991678 10.255.253.37 > 10.10.80.116: icmp: echo request 18:11:12.991976 10.10.80.116 > 10.255.253.37: icmp: echo reply 18:11:13.048172 10.255.253.37.49331 > 10.10.80.116.389: P 351:363(12) ack 1 win 67 (DF) 18:11:13.159407 10.10.80.116.389 > 10.255.253.37.49331: . ack 363 win 65173 (DF) 18:11:13.217883 10.255.253.37.49331 > 10.10.80.116.389: P 363:713(350) ack 1 win 67 (DF) 18:11:13.378146 10.10.80.116.389 > 10.255.253.37.49331: . ack 713 win 64823 (DF) 18:11:39.979918 10.255.253.37.49342 > 10.10.80.116.135: R 117:117(0) ack 1 win 0 (DF) 18:11:39.985059 10.255.253.37.49346 > 10.10.80.116.135: S 1542858070:1542858070(0) win 8192 <mss 1160,nop,wscale 8,nop,nop,sackOK> (DF) 18:11:39.985363 10.10.80.116.135 > 10.255.253.37.49346: S 2787720298:2787720298(0) ack 1542858071 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK> 18:11:40.039608 10.255.253.37.49346 > 10.10.80.116.135: . ack 1 win 67 (DF) 18:11:40.042048 10.255.253.37.49346 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:11:41.114397 10.255.253.37.49346 > 10.10.80.116.135: P 1:117(116) ack 1 win 67 (DF) 18:11:41.114605 10.10.80.116.135 > 10.255.253.37.49346: . ack 117 win 65419 (DF) Same deal, stand alone acks work fine but acks with data do not go through. Any suggestions on where I should go with this? This is pretty odd to me, as other applications work just fine with the same rules. Nothing gets blocked and no new states are created. The packet comes in, and it never comes out. Thanks for any help. 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
