Re: problems with emails through pf

[Dirk Mast]

Stuart Henderson wrote:

> On 2010-01-12, Dirk Mast  wrote:
>> Dirk Mast wrote:
>>
>>> Peter N. M. Hansteen wrote:
>>
 the problem went away.  tcpdump output of successful and failing
 connetions would be instructive, along with the actual error messages,
 if any.
>>
>> Request to wiki (see those long timestamps), hope this helps_
>>
>> Jan 12 23:22:06.181513 PPPoE
>> code Session, version 1, type 1, id 0x0580, length 114
>> IP: 195.50.140.178.53 > x.x.x.x.18336: 26867 2/0/1 CNAME
>> rr.esams.wikimedia.org., A 91.198.174.2 (84)
>> Jan 12 23:22:06.184287 PPPoE
>> code Session, version 1, type 1, id 0x0580, length 62
>> IP: x.x.x.x.51519 > 91.198.174.2.80: S 126511392:126511392(0) win
>> 5840  (DF)
> 
> 
> Your 'match in all scrub (no-df max-mss 1440)' is not affecting
> the mss on these packets, take a close look at your ruleset to try
> and work out why, though it might be as simple as removing 'in'..

It seems it was as simple as removing in!

> 91.198.174.3.80: S 4156933704:4156933704(0) win 5840 

Re: problems with emails through pf

[Stuart Henderson]

On 2010-01-12, Dirk Mast  wrote:
> Dirk Mast wrote:
>
>> Peter N. M. Hansteen wrote:
>
>>> the problem went away.  tcpdump output of successful and failing
>>> connetions would be instructive, along with the actual error messages,
>>> if any.
>
> Request to wiki (see those long timestamps), hope this helps_
>
> Jan 12 23:22:06.181513 PPPoE
> code Session, version 1, type 1, id 0x0580, length 114
> IP: 195.50.140.178.53 > x.x.x.x.18336: 26867 2/0/1 CNAME
> rr.esams.wikimedia.org., A 91.198.174.2 (84)
> Jan 12 23:22:06.184287 PPPoE
> code Session, version 1, type 1, id 0x0580, length 62
> IP: x.x.x.x.51519 > 91.198.174.2.80: S 126511392:126511392(0) win
> 5840  (DF)


Your 'match in all scrub (no-df max-mss 1440)' is not affecting
the mss on these packets, take a close look at your ruleset to try
and work out why, though it might be as simple as removing 'in'..


> Peter N. M. Hansteen wrote:
>> lscarne...@veltrac.com.br writes:
>> 
>>> My script is very simple (as you will see below), but by some reason,
>>> my machines behind the firewall can't send large emails, or emails
>>> with attached files.
>> 
>> You don't offer any details of the other parts of the mail handling
>> setup, but my first suspect would be content filtering of some kind
>> kicks in noticeably only when there's attachments to be dechiphered.

If it's happening when sending everywhere, MTU/MSS problems are
more likely.


>> My other suspect is that
>> 
>>> match in all scrub (no-df)
>> 
>> somehow tickles the receiving end the wrong way.  Others have reported
>> to me privately that going from 4.4 and
>> 
>> scrub in all
>> 
>> to 4.6 and
>> 
>> match in all scrub (reassemble tcp)
>> 
>> worked OK on most traffic, but slowed down some https traffic
>> horribly.  Then some apparently random experimentation lead to trying
>> different max-mss values and with
>> 
>> match in all scrub (no-df max-mss 1440)
>> 
>> the problem went away.  tcpdump output of successful and failing
>> connetions would be instructive, along with the actual error messages,
>> if any.

The sense of 'no-df' was inverted in 4.6, fixed in -current.


revision 1.120
date: 2009/09/01 15:51:06;  author: jsing;  state: Exp;  lines: +1 -1
Clear the IP_DF bit if no-df is enabled, not if it is not enabled.

Issue reported by Matthew Dempsky. Same fix suggested by fg...@.

Re: problems with emails through pf

[Dirk Mast]

Dirk Mast wrote:

> Peter N. M. Hansteen wrote:

>> the problem went away.  tcpdump output of successful and failing
>> connetions would be instructive, along with the actual error messages,
>> if any.

Request to wiki (see those long timestamps), hope this helps_

Jan 12 23:22:06.181513 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 114  
   
IP: 195.50.140.178.53 > x.x.x.x.18336: 26867 2/0/1 CNAME 
rr.esams.wikimedia.org., A 91.198.174.2 (84)
   
Jan 12 23:22:06.184287 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 62   
   
IP: x.x.x.x.51519 > 91.198.174.2.80: S 126511392:126511392(0) win 
5840  (DF)
  
Jan 12 23:22:09.182870 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 62   
   
IP: x.x.x.x.51519 > 91.198.174.2.80: S 126511392:126511392(0) win 
5840  (DF)
  
Jan 12 23:22:15.182651 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 62   
   
IP: x.x.x.x.51519 > 91.198.174.2.80: S 126511392:126511392(0) win 
5840  (DF)
  
Jan 12 23:22:15.700298 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 62   
   
IP: 91.198.174.2.80 > x.x.x.x.51519: S 4264277910:4264277910(0) ack 
126511393 win 5792  (DF) 
Jan 12 23:22:15.700652 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 54   
   
IP: x.x.x.x.51519 > 91.198.174.2.80: . ack 1 win 46 
 (DF) 

Jan 12 23:22:15.700784 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 507  
   
IP: x.x.x.x.51519 > 91.198.174.2.80: P 1:454(453) ack 1 win 46 
 (DF) 
 
Jan 12 23:22:16.387740 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 449  
   
IP: 91.198.174.2.80 > x.x.x.x.51519: P 1:396(395) ack 454 win 14 
 (DF) 
   
Jan 12 23:22:16.388127 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 54   
   
IP: x.x.x.x.51519 > 91.198.174.2.80: . ack 396 win 54 
 (DF) 
  
Jan 12 23:22:16.399542 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 77   
   
IP: x.x.x.x.38781 > 195.50.140.178.53: 14313+% [1au] A? 
bits.wikimedia.org. (47) 
Jan 12 23:22:16.421172 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 141  
   
IP: 195.50.140.178.53 > x.x.x.x.38781: 14313 3/0/1 CNAME bits-
geo.wikimedia.org., CNAME[|domain]  
  
Jan 12 23:22:16.422460 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 83   
   
IP: x.x.x.x.24926 > 195.50.140.178.53: 2994+% [1au] A? 
bits.esams.wikimedia.org. (53)
Jan 12 23:22:16.444376 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 99   
   
IP: 195.50.140.178.53 > x.x.x.x.24926: 2994 1/0/1 A 91.198.174.2 
(69)
Jan 12 23:22:16.470504 PPPoE
   
code Session, version 1, type 1, id 0x0580, length 62   
   
IP: x.x.x.x.63692 > 91.1

Re: problems with emails through pf

[Dirk Mast]

Peter N. M. Hansteen wrote:

> lscarne...@veltrac.com.br writes:
> 
>> My script is very simple (as you will see below), but by some reason,
>> my machines behind the firewall can't send large emails, or emails
>> with attached files.
> 
> You don't offer any details of the other parts of the mail handling
> setup, but my first suspect would be content filtering of some kind
> kicks in noticeably only when there's attachments to be dechiphered.
> 
> My other suspect is that
> 
>> match in all scrub (no-df)
> 
> somehow tickles the receiving end the wrong way.  Others have reported
> to me privately that going from 4.4 and
> 
> scrub in all
> 
> to 4.6 and
> 
> match in all scrub (reassemble tcp)
> 
> worked OK on most traffic, but slowed down some https traffic
> horribly.  Then some apparently random experimentation lead to trying
> different max-mss values and with
> 
> match in all scrub (no-df max-mss 1440)
> 
> the problem went away.  tcpdump output of successful and failing
> connetions would be instructive, along with the actual error messages,
> if any.
> 
> - P

I too have this feeling, that things somehow got really slow,
since scrub went away and match in scrub came.
I'm using match in all scrub (no-df max-mss 1440)
but some pages get weird TCP DUP ACKS, OUT-OF-ORDER Packets and
Previous Segment Lost (Wireshark slang).

Wikipedia is such a page for example - takes about 10 seconds to load 
sometimes.

I don't think I had this with 4.5.

I'm running an Alix 2c3 board, with pppoe to DSL.


OpenBSD 4.6-current (GENERIC) #452: Thu Dec 10 15:52:44 MST 2009
  
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC 
  
RTC BIOS diagnostic error 80 
  
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
  
real mem  = 268009472 (255MB)   
  
avail mem = 251064320 (239MB)   
  
RTC BIOS diagnostic error 80 
  
mainbus0 at root
  
bios0 at mainbus0: AT/286+ BIOS, date 01/27/08, BIOS32 rev. 0 @ 0xfceb2 
  
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
  
pcibios0: pcibios_get_intr_routing - function not supported 
  
pcibios0: PCI IRQ Routing information unavailable.  
  
pcibios0: PCI bus #0 is the last bus
  
bios0: ROM list: 0xe/0xa800 
  
cpu0 at mainbus0: (uniprocessor)
  
pci0 at mainbus0 bus 0: configuration mode 1 (bios) 
  
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31  
  
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES 
  
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, 
address 00:0d:b9:12:6b:04   
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x004063, model 0x0034  
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, 
address 00:0d:b9:12:6b:05  
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x004063, model 0x0034  
vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, 
address 00:0d:b9:12:6b:06
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x004063, model 0x0034
ath0 at pci0 dev 12 function 0 "Atheros AR2413" rev 0x01: irq 9
ath0: AR2413 7.8 phy 4.5 rf 5.6, FCC2A*, address 00:1d:0f:af:98:88
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 0, 32-bit 
3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 4-sector PIO, LBA, 1953MB, 4001760 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 15, version 
1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pcppi0 at isa0 port 0x61
midi0 at pcppi0: 
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: re

Re: problems with emails through pf

[Leonardo Carneiro]

Ignore. I junt found that tcpdump comes with the system.

*Leonardo de Souza Carneiro*
*Veltrac - Tecnologia em Logmstica.*
lscarne...@veltrac.com.br 
http://www.veltrac.com.br 
/Fone Com.: (43)2105-5601/
/R. Para 162 - CENTRO/
/Londrina- PR/
/Cep: 86010-450/



Leonardo Carneiro escreveu:

Hi everyone.

I tried with max-mss 1440 and this really solved my problem. Tks everyone

I didn't found the tcpdump in the packages repo, and when i use ntop, 
somehow my net.inet.ip.forwarding is set to 0!

Is avaible via ports, i guess?

*Leonardo de Souza Carneiro*
*Veltrac - Tecnologia em Logmstica.*
lscarne...@veltrac.com.br 
http://www.veltrac.com.br 
/Fone Com.: (43)2105-5601/
/R. Para 162 - CENTRO/
/Londrina- PR/
/Cep: 86010-450/



Lars Nooden escreveu:

Thanks Robert and Peter.

Robert wrote:
 

You probalby are using an uplink with a MTU lower than 1500.



Peter wrote:
 

match in all scrub (no-df max-mss 1440)

the problem went away.  tcpdump output of successful and failing
connetions would be instructive, along with the actual error
messages, if any.



Setting the maximum segment size to a smaller number seems to have
helped noticeably on my ADSL connection.

What should one look for in the tcpdump output?  Here is the tail end of
a timed out connection to a web server.

Regards,
/Lars

 17:40:58.051513 upload.esams.wikimedia.org.www > foo.54960: F
1474:1474(0) ack 530 win 14  (DF)
 17:40:58.051988 foo.50486 > upload.esams.wikimedia.org.www: . ack
12226 win 16384 
 17:40:58.052006 foo.54960 > upload.esams.wikimedia.org.www: . ack
1475 win 16384 
 17:41:09.729879 foo.63952 > upload.esams.wikimedia.org.www: F
542:542(0) ack 851 win 16384 
 17:41:09.729897 foo.50486 > upload.esams.wikimedia.org.www: F
487:487(0) ack 12226 win 16384 
 17:41:09.729955 foo.54960 > upload.esams.wikimedia.org.www: F
530:530(0) ack 1475 win 16384 
 17:41:09.781579 upload.esams.wikimedia.org.www > foo.63952: . ack
543 win 14  (DF)
 17:41:09.783580 upload.esams.wikimedia.org.www > foo.50486: . ack
488 win 14  (DF)
 17:41:09.783596 upload.esams.wikimedia.org.www > foo.54960: . ack
531 win 14  (DF)

Re: problems with emails through pf

[Leonardo Carneiro]

Hi everyone.

I tried with max-mss 1440 and this really solved my problem. Tks everyone

I didn't found the tcpdump in the packages repo, and when i use ntop, 
somehow my net.inet.ip.forwarding is set to 0!

Is avaible via ports, i guess?

*Leonardo de Souza Carneiro*
*Veltrac - Tecnologia em Logmstica.*
lscarne...@veltrac.com.br 
http://www.veltrac.com.br 
/Fone Com.: (43)2105-5601/
/R. Para 162 - CENTRO/
/Londrina- PR/
/Cep: 86010-450/



Lars Nooden escreveu:

Thanks Robert and Peter.

Robert wrote:
  

You probalby are using an uplink with a MTU lower than 1500.



Peter wrote:
  

match in all scrub (no-df max-mss 1440)

the problem went away.  tcpdump output of successful and failing
connetions would be instructive, along with the actual error
messages, if any.



Setting the maximum segment size to a smaller number seems to have
helped noticeably on my ADSL connection.

What should one look for in the tcpdump output?  Here is the tail end of
a timed out connection to a web server.

Regards,
/Lars

 17:40:58.051513 upload.esams.wikimedia.org.www > foo.54960: F
1474:1474(0) ack 530 win 14  (DF)
 17:40:58.051988 foo.50486 > upload.esams.wikimedia.org.www: . ack
12226 win 16384 
 17:40:58.052006 foo.54960 > upload.esams.wikimedia.org.www: . ack
1475 win 16384 
 17:41:09.729879 foo.63952 > upload.esams.wikimedia.org.www: F
542:542(0) ack 851 win 16384 
 17:41:09.729897 foo.50486 > upload.esams.wikimedia.org.www: F
487:487(0) ack 12226 win 16384 
 17:41:09.729955 foo.54960 > upload.esams.wikimedia.org.www: F
530:530(0) ack 1475 win 16384 
 17:41:09.781579 upload.esams.wikimedia.org.www > foo.63952: . ack
543 win 14  (DF)
 17:41:09.783580 upload.esams.wikimedia.org.www > foo.50486: . ack
488 win 14  (DF)
 17:41:09.783596 upload.esams.wikimedia.org.www > foo.54960: . ack
531 win 14  (DF)

Re: problems with emails through pf

[Lars Nooden]

Thanks Robert and Peter.

Robert wrote:
> You probalby are using an uplink with a MTU lower than 1500.

Peter wrote:
>   match in all scrub (no-df max-mss 1440)
>
> the problem went away.  tcpdump output of successful and failing
> connetions would be instructive, along with the actual error
> messages, if any.

Setting the maximum segment size to a smaller number seems to have
helped noticeably on my ADSL connection.

What should one look for in the tcpdump output?  Here is the tail end of
a timed out connection to a web server.

Regards,
/Lars

 17:40:58.051513 upload.esams.wikimedia.org.www > foo.54960: F
1474:1474(0) ack 530 win 14  (DF)
 17:40:58.051988 foo.50486 > upload.esams.wikimedia.org.www: . ack
12226 win 16384 
 17:40:58.052006 foo.54960 > upload.esams.wikimedia.org.www: . ack
1475 win 16384 
 17:41:09.729879 foo.63952 > upload.esams.wikimedia.org.www: F
542:542(0) ack 851 win 16384 
 17:41:09.729897 foo.50486 > upload.esams.wikimedia.org.www: F
487:487(0) ack 12226 win 16384 
 17:41:09.729955 foo.54960 > upload.esams.wikimedia.org.www: F
530:530(0) ack 1475 win 16384 
 17:41:09.781579 upload.esams.wikimedia.org.www > foo.63952: . ack
543 win 14  (DF)
 17:41:09.783580 upload.esams.wikimedia.org.www > foo.50486: . ack
488 win 14  (DF)
 17:41:09.783596 upload.esams.wikimedia.org.www > foo.54960: . ack
531 win 14  (DF)

Re: problems with emails through pf

[Robert]

On Mon, 11 Jan 2010 17:14:15 -0200
Leonardo Carneiro  wrote:

> Hi again. Removing the scrub rule (which i do not really know what
> does) solved my problem, including a similar problem sending files
> through scp. Here is the line:
> 
> match in all scrub (no-df)
> 
> What does this line here does? I'd read something about packet 
> normalization. Also i'd read in the FAQ that use it is a good pratice 
> (though i really didn't understood why).
> 
> Resuming: Am i in trouble for not using this line?

On OpenBSD manpages are actually worth reading.

man pf.conf
/Scrub

It's explained in detail.

To your initial problem, Peter gave you the clue to (most likely) fix
it, while keeping scrub.
You probalby are using an uplink with a MTU lower than 1500.
the "max-mss" option reduces the outgoing packet size, so that they
don't get fragmented. Using this is a must on todays internet with
something like a DSL line/pppoe. 1440 is a value that seems to work for
almost everybody everywhere with such a connection.
(If you want to know where that number comes from, start substracting
header overhead for each layer from the package size.)

- Robert

Re: problems with emails through pf

[Leonardo Carneiro]

Hi again. Removing the scrub rule (which i do not really know what does) 
solved my problem, including a similar problem sending files through 
scp. Here is the line:


   match in all scrub (no-df)

What does this line here does? I'd read something about packet 
normalization. Also i'd read in the FAQ that use it is a good pratice 
(though i really didn't understood why).


Resuming: Am i in trouble for not using this line?

*Leonardo de Souza Carneiro*
*Veltrac - Tecnologia em Logmstica.*
lscarne...@veltrac.com.br 
http://www.veltrac.com.br 
/Fone Com.: (43)2105-5601/
/R. Para 162 - CENTRO/
/Londrina- PR/
/Cep: 86010-450/



lscarne...@veltrac.com.br escreveu:

Hello everyone,

I'm a newcommer in the OpenBSD world and i'm quite excited with the 
system.


I'm using OpenBSD as my firewall/gateway box, and now i'm getting some
unforeseen behaviors.

My script is very simple (as you will see below), but by some reason,
my machines behind the firewall can't send large emails, or emails
with attached files. This behavior is not reproducible in other links
(like in my home, where my machine is just behind a dsl modem/router).

This very message i'm sending via my home computer, through a remote
session, since i can't send it through my local computer.

I have been reading through the FAQ but didn't find anything that
could help me out. Does anyone know what could be happening?

Tks in advance and sorry for my poor english.

Here is my pf.conf file:

inet_iface="rl0"
lan_tec_iface="re0"

inet_ip="10.1.3.2"
lan_tec_ip="192.168.1.1"


lan_tec_net="192.168.1.0/24"

fileserver="192.168.1.2"
trackserver="192.168.1.3"
sininho="192.168.1.102"
snipes="192.168.1.103"
dupas="192.168.1.110"
vitor="192.168.1.155"

fw_ext_services="{ 22, 113 }"
icmp_types="{ echoreq, unreach }"

## Block-policy
set block-policy return

## Log na interface externa
set loginterface $inet_iface

## Liberar a interface de loopback de qualquer regra
set skip on lo

## Scrub em todo o trafego (normalizagco)
match in all scrub (no-df)

## NAT em na interface externa para todas as interfaces internas
nat on $inet_iface from !($inet_iface) to any -> $inet_ip

## Redirects

# FILESERVER
# openfire
rdr on $lan_tec_iface proto tcp from any to 201.22.74.237  port {
5222,  } ->
$fileserver
rdr on $inet_iface proto tcp from any to any port { 5222,  }
-> $fileserver

# TRACKSERVER
# gateway no trackserver
rdr on $inet_iface proto udp from any to any port 8280 -> 
$trackserver


# SININHO
# banco
rdr on $inet_iface proto tcp from any to any port 5432 -> $sininho
# vnc
rdr on $inet_iface proto tcp from any to any port 5901 -> $sininho
rdr on $inet_iface proto udp from any to any port 5901 -> $sininho
# ssh
rdr on $inet_iface proto tcp from any to any port 9132 -> $sininho

# SNIPES
# gateway
rdr on $inet_iface proto udp from any to any port 10050 -> $snipes

## Filters
# Bloqueia todo o trafego entrando na interface externa, por padrco
block in on $inet_iface

# Permite todo o trafego saindo em qualquer interface, por padrco
pass out keep state

# Permite trafego entrando nas interfaces internas
pass in on ! $inet_iface keep state

# Protegco antispoof para as interfaces internas
antispoof quick for $lan_tec_iface


# Permitir portas de acesso ao prsprio firewall pela internet
pass in on $inet_iface inet proto tcp from any to $inet_ip port
$fw_ext_services
flags S/SA keep state
pass in on ! $inet_iface inet from $lan_tec_net to any

# FILESERVER
# openfire
pass in on $inet_iface inet proto tcp from any to $fileserver
port { 5222,  }
flags S/SA synproxy state

# TRACKSERVER
# gateway no trackserver
pass in on $inet_iface inet proto udp from any to $trackserver 
port 8280


# SININHO
# banco
pass in on $inet_iface inet proto tcp from any to $sininho port
5432 flags S/SA
synproxy state
# vnc
pass in on $inet_iface inet proto tcp from any to $sininho port
5901 flags S/SA
synproxy state
pass in on $inet_iface inet proto udp from any to $sininho port 5901
# ssh
pass in on $inet_iface inet proto tcp from any to $sininho port
9132 flags S/SA
synproxy state

# Snipes
# gateway
pass in on $inet_iface inet proto udp from any to $snipes port 10050

Re: problems with emails through pf

[Peter N. M. Hansteen]

lscarne...@veltrac.com.br writes:

> My script is very simple (as you will see below), but by some reason,
> my machines behind the firewall can't send large emails, or emails
> with attached files. 

You don't offer any details of the other parts of the mail handling
setup, but my first suspect would be content filtering of some kind
kicks in noticeably only when there's attachments to be dechiphered.

My other suspect is that 

> match in all scrub (no-df)

somehow tickles the receiving end the wrong way.  Others have reported
to me privately that going from 4.4 and 

scrub in all

to 4.6 and

match in all scrub (reassemble tcp)

worked OK on most traffic, but slowed down some https traffic
horribly.  Then some apparently random experimentation lead to trying
different max-mss values and with

match in all scrub (no-df max-mss 1440)

the problem went away.  tcpdump output of successful and failing
connetions would be instructive, along with the actual error messages,
if any.

- P
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

problems with emails through pf

[lscarneiro]

Hello everyone,

I'm a newcommer in the OpenBSD world and i'm quite excited with the system.

I'm using OpenBSD as my firewall/gateway box, and now i'm getting some
unforeseen behaviors.

My script is very simple (as you will see below), but by some reason,
my machines behind the firewall can't send large emails, or emails
with attached files. This behavior is not reproducible in other links
(like in my home, where my machine is just behind a dsl modem/router).

This very message i'm sending via my home computer, through a remote
session, since i can't send it through my local computer.

I have been reading through the FAQ but didn't find anything that
could help me out. Does anyone know what could be happening?

Tks in advance and sorry for my poor english.

Here is my pf.conf file:

inet_iface="rl0"
lan_tec_iface="re0"

inet_ip="10.1.3.2"
lan_tec_ip="192.168.1.1"


lan_tec_net="192.168.1.0/24"

fileserver="192.168.1.2"
trackserver="192.168.1.3"
sininho="192.168.1.102"
snipes="192.168.1.103"
dupas="192.168.1.110"
vitor="192.168.1.155"

fw_ext_services="{ 22, 113 }"
icmp_types="{ echoreq, unreach }"

## Block-policy
set block-policy return

## Log na interface externa
set loginterface $inet_iface

## Liberar a interface de loopback de qualquer regra
set skip on lo

## Scrub em todo o trafego (normalizagco)
match in all scrub (no-df)

## NAT em na interface externa para todas as interfaces internas
nat on $inet_iface from !($inet_iface) to any -> $inet_ip

## Redirects

# FILESERVER
# openfire
rdr on $lan_tec_iface proto tcp from any to 201.22.74.237  port {
5222,  } ->
$fileserver
rdr on $inet_iface proto tcp from any to any port { 5222,  }
-> $fileserver

# TRACKSERVER
# gateway no trackserver
rdr on $inet_iface proto udp from any to any port 8280 -> $trackserver

# SININHO
# banco
rdr on $inet_iface proto tcp from any to any port 5432 -> $sininho
# vnc
rdr on $inet_iface proto tcp from any to any port 5901 -> $sininho
rdr on $inet_iface proto udp from any to any port 5901 -> $sininho
# ssh
rdr on $inet_iface proto tcp from any to any port 9132 -> $sininho

# SNIPES
# gateway
rdr on $inet_iface proto udp from any to any port 10050 -> $snipes

## Filters
# Bloqueia todo o trafego entrando na interface externa, por padrco
block in on $inet_iface

# Permite todo o trafego saindo em qualquer interface, por padrco
pass out keep state

# Permite trafego entrando nas interfaces internas
pass in on ! $inet_iface keep state

# Protegco antispoof para as interfaces internas
antispoof quick for $lan_tec_iface


# Permitir portas de acesso ao prsprio firewall pela internet
pass in on $inet_iface inet proto tcp from any to $inet_ip port
$fw_ext_services
flags S/SA keep state
pass in on ! $inet_iface inet from $lan_tec_net to any

# FILESERVER
# openfire
pass in on $inet_iface inet proto tcp from any to $fileserver
port { 5222,  }
flags S/SA synproxy state

# TRACKSERVER
# gateway no trackserver
pass in on $inet_iface inet proto udp from any to $trackserver port 8280

# SININHO
# banco
pass in on $inet_iface inet proto tcp from any to $sininho port
5432 flags S/SA
synproxy state
# vnc
pass in on $inet_iface inet proto tcp from any to $sininho port
5901 flags S/SA
synproxy state
pass in on $inet_iface inet proto udp from any to $sininho port 5901
# ssh
pass in on $inet_iface inet proto tcp from any to $sininho port
9132 flags S/SA
synproxy state

# Snipes
# gateway
pass in on $inet_iface inet proto udp from any to $snipes port 10050