Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 2222 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SLB/PF blocks ACK-Packages

guawhitehawk
Hi,

i have a weird behaviour with one of our Partners. We drive a IPSec-VPN without any issues with AES256/SHA-1 and DHE-Group 5.

Furthermore our Partner is allowed to connect to a Server Load Balancer via HTTPS through it which resolves to two working real servers. The API-Connection and Communication works great but we have some blocked ACK-FIN and ACK-RST packages which i cannot explain. (Attached picture1)

The SLB-Rule is HTTPS with the virtual-IP and two real-servers monitored by a 5s delayed ping. Both servers are up and weighted 100 without a persistence and without auto-PF-Rules.

The according PF-Rule #16 (seen in picture 1) says that all partners-IPs (Same as in VPN) are allowed to connect to those two real-servers using HTTPS (with logging enabled).

An according blocked ulogd-entry looks like this (added explanation and removed partners real ip): 

2013-09-30T09:26:03.411217+02:00 fwhost.example.com 2013: 09:30-09:26:03 ulogd[8671]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="lag1" outitf="lag1" srcmac="0:1b:ed:2[:D]c:0" dstmac="90:e2:ba:9:52:c0" srcip="PARTNER_IP" dstip="10.30.160.9(our SLB IP)" proto="6" length="40" tos="0x00" prec="0x00" ttl="24" srcport="15928" dstport="443" tcpflags="ACK FIN" ,id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="lag1" outitf="lag1" srcmac="0:1b:ed:2[:D]c:0" dstmac="90:e2:ba:9:52:c0" srcip="PARTNER_IP" dstip="10.30.160.9" proto="6" length="40" tos="0x00" prec="0x00" ttl="24" srcport="15928" dstport="443" tcpflags="ACK FIN"


This thread was automatically locked due to age.
Parents
  • 0
    After talking to our partner and checking his firewall and clients, its because his clients sending a final ACK-FIN/RST (valid!) and it looks like our firewall has a low TCP Session Timeout, therefore it drops those packages.

    On our partners side theres a Checkpoint FW and the appropiate checkbox is called "TCP end timeout". Is there something similiar in the UTM (SLB Settings?)

    I think the problem is the SLBs persistence which is NOT set, therefore our firewall cannot reference the ACK package to the already closed session. Can this cause this "issue"?
Reply
  • 0
    After talking to our partner and checking his firewall and clients, its because his clients sending a final ACK-FIN/RST (valid!) and it looks like our firewall has a low TCP Session Timeout, therefore it drops those packages.

    On our partners side theres a Checkpoint FW and the appropiate checkbox is called "TCP end timeout". Is there something similiar in the UTM (SLB Settings?)

    I think the problem is the SLBs persistence which is NOT set, therefore our firewall cannot reference the ACK package to the already closed session. Can this cause this "issue"?
Children
No Data