PF PF does not clear DF bit both 1433 and 445 traffic

alfa

alfa

Hi,
i am trying to clear [DF] bit coming from VPN traffic. I added below the PF rules but not worked
Especially 1433 Database traffic is very slow in VPN tunnel on my network . I think that it is related with DF bits
thanks in advance

WAN = igb5
LAN= igb1

Code: 
table <vpn_networks> { 192.168.254.0/24 }

scrub on wg1 inet all no-df fragment reassemble
scrub from any to <vpn_networks>  no-df
scrub from <vpn_networks> to any  no-df

scrub on igb5 inet all no-df   fragment reassemble
scrub on igb1 inet all no-df   fragment reassemble

Code: 
192.168.1.77.62171 > 192.168.254.2.445: Flags [S], cksum 0x9a48 (correct), seq 1582324813, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:50:28.537090 IP (tos 0x0, ttl 128, id 2953, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.77.62178 > 192.168.254.2.445: Flags [S], cksum 0xf473 (correct), seq 3315178193, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:50:29.548351 IP (tos 0x0, ttl 128, id 2954, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.77.62178 > 192.168.254.2.445: Flags [S], cksum 0xf473 (correct), seq 3315178193, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:50:31.563222 IP (tos 0x0, ttl 128, id 2955, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.77.62178 > 192.168.254.2.445: Flags [S], cksum 0xf473 (correct), seq 3315178193, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:50:35.570853 IP (tos 0x0, ttl 128, id 2956, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.77.62178 > 192.168.254.2.445: Flags [S], cksum 0xf473 (correct), seq 3315178193, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:50:43.581009 IP (tos 0x0, ttl 128, id 2957, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.77.62178 > 192.168.254.2.445: Flags [S], cksum 0xf473 (correct), seq 3315178193, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:50:49.605645 IP (tos 0x0, ttl 128, id 2958, offset 0, flags [DF], proto TCP (6), length 52)
 
VladiBG said:
use mss 1360

clearing DF or blocking ICMP will break PMTUD
Click to expand...
i added below the rules but nothing changed database operations are still very slow

Code: 
scrub on wg1 inet all max-mss 1360
scrub on igb0 inet all max-mss 1360
scrub on igb1 inet all max-mss 1360
 
According to manual
no-df
Clears the dont-fragment bit from a matching IP packet. Some
operating systems are known to generate fragmented packets with the
dont-fragment bit set. This is particularly true with NFS. Scrub
will drop such fragmented dont-fragment packets unless no-df is
specified.

Unfortunately some operating systems also generate their
dont-fragment packets with a zero IP identification field.
Clearing the dont-fragment bit on packets with a zero IP ID may
cause deleterious results if an upstream router later fragments the
packet. Using the modifier (see below) is recommended in
combination with the no-df modifier to ensure unique IP
identifiers.
Click to expand...
So, you need something like that:
Code: 
scrub on igb1 inet all (no-df random-id)
 
Hi i want to give some extra details to be clear. I used a software that acesses a database on a SMB share hosted by Windows server 2019 .
When I tried to run the software it operates extremely slow. Now I switched tcpdump to wireshark and listen the traffic and i saw SMB2 errors .
So in this stuation i should solve this problem before MSS correction .
Sorry to bother you thanks for your interest

Code: 
SMB2 traffic . Getinfo Response, Error: STATUS_ACCESS_DENIED
...
281 Session Setup NTLMSSP_AUTH, User: \
130 Session Setup Response,Error: STATUS_ACCESS_DENIED
smb2.png
 
I thought that the packets' mtu where sent by client from pc/databse server over wireguard is higher than tunnel mtu (1420) so i sniffed wg0 interface using tcpdump and saw DF bits
so i tried to clear that DF bits to fragment packets. But i couldn't clear DF bits at the end.
kalleboy said:
Hi alfa - excuse me just wanted to ask, I wonder why should you/we clear DF bit coming from VPN traffic?
Click to expand...
 
Last edited:
You must log in or register to reply here.
Back
Top