anonymous VPN service and openbsd..
Hi, has anybody tried to setup a openvpn/pptp connection on there OpenBSD firewall to a anonymous VPN service and redirecting only torrent traffic trough the tunnel ? -- Mvh Daniel Rapp
FW: Strange smtp problem..
Update:
I turned debug urgent on in pf and i get these in the logs.
pf: BAD state: TCP aaa.aaa.aaa.aaa:25 aaa.aaa.aaa.aaa:25
ccc.ccc.ccc.ccc:2554 [lo=1937461566 high=1937478751 win=65535 modulator=0]
[lo=740836633 high=740902095 win=17184 modulator=0] 4:4 R seq=1937461566
ack=740836633 len=0 ackskew=0 pkts=2:4 dir=in,fwd
pf: State failure on: |
Aaa.aaa.aaa.aaa = smtp server behind obsd 3.9 bridge
Bbb.bbb.bbb.bbb = external smtp server
Any thoughts ?
Mvh
Daniel Rapp
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Daniel Rapp
Sent: den 4 juli 2006 12:13
To: pf@benzedrine.cx
Subject: Strange smtp problem..
Hi, (sorry for the long mail..)i am having a strange problem
with a clients server witch is sitting behind a obsd3.9
bridge hopefully somebody can shed some light on it..
The server sits on a DMZ behind a bridge, there is a couple
of other machines behind there to and non of them are having
any problem...that we know of.
There seem to be a problem with the connection trough the fw
to the client mail server.
This is what the customer gets in his maillog (Mdeamon):
Mon 2006-07-03 13:42:16: Accepting SMTP connection from
[xx.xx.xx.xx : 64148] Mon 2006-07-03 13:42:16: -- 220
foo.net ESMTP Mon, 03 Jul 2006 13:42:16 +0200 Mon 2006-07-03
13:45:26: Error reading from socket!
Mon 2006-07-03 13:45:26: Winsock Error 10054 Connection was
reset by the other side!
Mon 2006-07-03 13:45:26: SMTP session terminated (Bytes
in/out: 0/73)
This happens a lot and from different hosts..and not all the
time But after a while the mail seems to get trough.
-
From pf.conf:
#aaa.aaa.aaa.aaa = client server
#Runtime Options
set timeout tcp.first 120
set timeout tcp.established 86400
set limit { states 1, frags 8000}
set timeout { adaptive.start 3000, adaptive.end 6000 } set
optimization normal set block-policy drop set loginterface
sis3 set skip on lo0
#Scrub
scrub on $WAN all reassemble tcp
no scrub on $WAN to aaa.aaa.aaa.aaa # Tryed different scrub
and no scrub rules but with the same result..
pass out quick on $WAN proto tcp all flags S/SA
pass in log (all) quick on sis3 inet proto tcp from any to
aaa.aaa.aaa.aaa port = smtp flags S/SA keep state label client_aaa
---
If i do a tcpdump -e -n -ttt -vv -i pflog0 i get:
Jul 04 11:06:51.960142 rule 88/(match) [uid 0, pid 11358]
pass out on sis3: aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.36842:
[|tcp] (DF) (ttl 128, id 2665, len 125) Jul 04
11:06:51.967327 rule 88/(match) [uid 0, pid 11358] pass in on
sis3: bbb.bbb.bbb.bbb.36842 aaa.aaa.aaa.aaa.25: [|tcp] (DF)
[tos 0x20] (ttl 58, id 48736, len 52, bad cksum 0! differs by 696c
Jul 04 11:48:30.655896 rule 88/(match) [uid 0, pid 6857] pass
in on sis3: bbb.bbb.bbb.bbb.2916 aaa.aaa.aaa.aaa.25: [|tcp]
(DF) (ttl 120, id 41051, len 46, bad cksum 0! differs by d64)
Jul 04 11:48:30.656547 rule 88/(match) [uid 0, pid 6857] pass
in on sis3: bbb.bbb.bbb.bbb.2916 aaa.aaa.aaa.aaa.25: [|tcp]
(DF) (ttl 120, id 41052, len 40, bad cksum 0! differs by d69)
Jul 04 11:48:30.656714 rule 88/(match) [uid 0, pid 6857] pass
out on sis3: aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2916:
[|tcp] (DF) (ttl 128, id 25485, len 40) Jul 04
11:48:30.657983 rule 88/(match) [uid 0, pid 6857] pass out on
sis3: aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2916: [|tcp] (DF)
(ttl 128, id 25486, len 66) Jul 04 11:48:30.658131 rule
88/(match) [uid 0, pid 6857] pass out on sis3:
aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2916: [|tcp] (DF) (ttl
128, id 25487, len 40) Jul 04 11:48:30.678318 rule 88/(match)
[uid 0, pid 6857] pass in on sis3: bbb.bbb.bbb.bbb.2916
aaa.aaa.aaa.aaa.25: [|tcp] (DF) (ttl 120, id 41053, len 40,
bad cksum 0! differs by d68)
Bad checksum on incoming packets ?, could that be the problem?
If i do a tcpdump -n -vv -i sis3 host aaa.aaa.aaa.aaa i get:
12:05:58.164470 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: S
[tcp sum ok] 2701663852:2701663852(0) win 64240 mss
1460,nop,nop,sackOK (DF) (ttl 120, id 15292, len 48)
12:05:58.164750 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: S
[tcp sum ok] 3645997308:3645997308(0) ack 2701663853 win
17520 mss 1460,nop,nop,sackOK (DF) (ttl 128, id 62899, len
48) 12:05:58.174420 bbb.bbb.bbb.bbb.2860
aaa.aaa.aaa.aaa.25: . [tcp sum ok] 1:1(0) ack 1 win 64240
(DF) (ttl 120, id 15293, len 40)
12:05:58.199337 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: P
1:74(73) ack 1 win 17520 (DF) (ttl 128, id 62900, len 113)
12:05:58.210634 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: P
[tcp sum ok] 1:13(12) ack 74 win 64167 (DF) (ttl 120, id
15302, len 52)
12:05:58.213567 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: P
74:127(53) ack 13 win 17508 (DF) (ttl 128, id 62901, len 93)
12:05:58.393083 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: .
[tcp sum ok] 13:13(0) ack 127 win 64114 (DF) (ttl 120, id
15318, len
RE: FW: Strange smtp problem..
Yes, that one loks like that.. adding osfp IRIX 6.5 15 = 49152:64:0:48:0x403 4 (TS=,M=*0,W=*0) 801005 adding osfp IRIX 6.5 16 = 49152:64:0:48:0x403 4 (TS=,M=*0,W=*0) 801006 pf: BAD state: TCP aaa.aaa.aaa.aaa:25 aaa.aaa.aaa.aaa:25 bbb.bbb.bbb.bbb:2554 [lo=1937461566 high=1937478751 win=65535 modulator=0] [lo=740836633 high=740902095 win=17184 modulator=0] 4:4 R seq=1937461566 ack=740836633 len=0 ackskew=0 pkts=2:4 dir=in,fwd pf: State failure on: | adding osfp IRIX 6.5 17 = 49152:64:0:48:0x403 4 (TS=,M=*0,W=*0) 801007 adding osfp IRIX 6.5 18 = 49152:64:0:48:0x403 4 (TS=,M=*0,W=*0) 801008 But i also has some others that looks a little better, but not with the same machine.. pf: BAD state: TCP ccc.ccc.ccc.ccc:1433 ccc.ccc.ccc.ccc:1433 ddd.ddd.ddd.ddd:4575 [lo=3065509305 high=3065574509 win=64064 modulator=3501616518 wscale=3] [lo=1992758873 high=1993270690 win=65494 modulator=778980472 wscale=0] 9:9 S seq=3275529855 ack=1992758873 len=0 ackskew=0 pkts=7:6 dir=in,fwd pf: State failure on: 1 | 5 Mvh Daniel Rapp -Original Message- From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] Sent: den 5 juli 2006 13:46 To: Daniel Rapp Cc: pf@benzedrine.cx Subject: Re: FW: Strange smtp problem.. On Wed, Jul 05, 2006 at 01:34:34PM +0200, Daniel Rapp wrote: pf: BAD state: TCP aaa.aaa.aaa.aaa:25 aaa.aaa.aaa.aaa:25 ccc.ccc.ccc.ccc:2554 [lo=1937461566 high=1937478751 win=65535 modulator=0] [lo=740836633 high=740902095 win=17184 modulator=0] 4:4 R seq=1937461566 ack=740836633 len=0 ackskew=0 pkts=2:4 dir=in,fwd pf: State failure on: | You're absolutely sure this is quoted/pasted correctly, the second line really has no numbers after the colon? Daniel smime.p7s Description: S/MIME cryptographic signature
RE: Strange smtp problem..
The pass out quick on $WAN proto tcp all flags S/SA that was just a editing bug.. I was changing it from modulate state to keep state but it didn't get saved right.. Probably to much coffee.. Or not enough.. I am going to try some more logging to see if I can find something. Thanks for the help. Mvh Daniel Rapp Incabus Systems AB Direkt: + 46 8 410 115 45 [EMAIL PROTECTED] -Original Message- From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] Sent: den 5 juli 2006 14:32 To: Daniel Rapp Cc: pf@benzedrine.cx Subject: Re: Strange smtp problem.. On Tue, Jul 04, 2006 at 12:12:51PM +0200, Daniel Rapp wrote: pass out quick on $WAN proto tcp all flags S/SA Why no 'keep state' here? You really only pass out SYNs, don't pass SYN+ACK back in, and neither pass further (non-SYN) packets? Makes no sense. If i do a tcpdump -e -n -ttt -vv -i pflog0 i get: Jul 04 11:48:30.678318 rule 88/(match) [uid 0, pid 6857] pass in on sis3: bbb.bbb.bbb.bbb.2916 aaa.aaa.aaa.aaa.25: [|tcp] (DF) (ttl 120, id 41053, len 40, bad cksum 0! differs by d68) Bad checksum on incoming packets ?, could that be the problem? Retry with added -s 1700 to the tcpdump command. The default snaplen is too short, truncating packets ([|tcp]), producing the checksum warnings. An thoughts ? I see nothing wrong with that dump. If that winsock error is reliable and means the server got a TCP RST, it almost certainly was the external peer sending it. You'll have to get a tcpdump capture of one connection that produces the error in the server, preferably on both interfaces of the bridge. Depending on traffic volume, it might be difficult to get, but try tcpdump'ing all port 25 traffic into a file, then wait until the next server error occurs, then filter the file using the peer's random port number. To prove that it's pf at fault producing the RST, you'll have to show that the server is receiving an RST, the RST was sent out from the bridge's internal interface, and that is has not arrived in on the bridge's external interface. Those peers don't happen to be all from China [1], by any chance? :) Daniel [1] http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-gre at-firewall-of-china/ smime.p7s Description: S/MIME cryptographic signature
Strange smtp problem..
:58.481407 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: P [tcp sum ok] 308:348(40) ack 89 win 17432 (DF) (ttl 128, id 62905, len 80) 12:05:58.504634 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . [tcp sum ok] 89:89(0) ack 348 win 63893 (DF) (ttl 120, id 15324, len 40) 12:05:59.066653 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 89:1549(1460) ack 348 win 63893 (DF) (ttl 120, id 15437, len 1500) 12:05:59.083808 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 1549:3009(1460) ack 348 win 63893 (DF) (ttl 120, id 15438, len 1500) 12:05:59.084257 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: . [tcp sum ok] 348:348(0) ack 3009 win 17520 (DF) (ttl 128, id 62906, len 40) 12:05:59.100520 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 3009:4469(1460) ack 348 win 63893 (DF) (ttl 120, id 15439, len 1500) 12:05:59.117717 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 4469:5929(1460) ack 348 win 63893 (DF) (ttl 120, id 15440, len 1500) 12:05:59.118190 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: . [tcp sum ok] 348:348(0) ack 5929 win 17520 (DF) (ttl 128, id 62907, len 40) 12:05:59.134145 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 5929:7389(1460) ack 348 win 63893 (DF) (ttl 120, id 15441, len 1500) 12:05:59.141687 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: P 7389:8281(892) ack 348 win 63893 (DF) (ttl 120, id 15442, len 932) 12:05:59.141996 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: . [tcp sum ok] 348:348(0) ack 8281 win 17520 (DF) (ttl 128, id 62908, len 40) 12:05:59.181316 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 8281:9741(1460) ack 348 win 63893 (DF) (ttl 120, id 15445, len 1500) 12:05:59.197660 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 9741:11201(1460) ack 348 win 63893 (DF) (ttl 120, id 15446, len 1500) 12:05:59.198096 aaa.aaa.aaa.aaa.25 bbb.bbb.bbb.bbb.2860: . [tcp sum ok] 348:348(0) ack 11201 win 17520 (DF) (ttl 128, id 62909, len 40) 12:05:59.214779 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 11201:12661(1460) ack 348 win 63893 (DF) (ttl 120, id 15447, len 1500) 12:05:59.231917 bbb.bbb.bbb.bbb.2860 aaa.aaa.aaa.aaa.25: . 12661:14121(1460) ack 348 win 63893 (DF) (ttl 120, id 15448, len 1500) If i check with etereal it seems like there is a lot of tcp dup ack and tcp retransmission.. An thoughts ? Mvh Daniel Rapp
