12-12-2009 02:55 PM - edited 12-12-2009 02:56 PM
Hello,
I am doing Policy Based Routing to ensure that all traffic with a destination of TCP Port 80 is sent to a squid web proxy operating in transparent mode.
This is on a 5GT ADSL/Wireless running ScreenOS 6.2.0r4
It works fine, apart from watching YouTube videos or any other traffic that takes a long time.
The problem is, the session information dies and the YouTube video stops. I have discovered that I need to remove he TCP Syn Check of flows - this fixes the problem.
What I can't figure out is why the session is being removed when there is obviously still traffic. Here is a snippet of traffic from a debug flow:
****** 47535.0: <Trust/wireless2> packet received [40]******
ipid = 59094(e6d6), @02281e94
packet passed sanity check.
flow_decap_vector IPv4 process
wireless2:20.1.1.1/25420->74.125.103.17/80,6<Root>
existing session found. sess token 3
flow got session.
flow session id 1727
flow_main_body_vector in ifp wireless2 out ifp N/A
flow vector index 0x103, vector addr 0x63db9dc, orig vector 0x63db9dc
tcp seq check.
post addr xlation: 20.1.1.1->74.125.103.17.
packet send out to 0015af66cba4 through wireless2
****** 47535.0: <Trust/wireless2> packet received [40]******
ipid = 59099(e6db), @02284f94
packet passed sanity check.
flow_decap_vector IPv4 process
wireless2:20.1.1.1/25420->74.125.103.17/80,6<Root>
existing session found. sess token 3
flow got session.
flow session id 1727
flow_main_body_vector in ifp wireless2 out ifp N/A
flow vector index 0x103, vector addr 0x63db9dc, orig vector 0x63db9dc
tcp seq check.
post addr xlation: 20.1.1.1->74.125.103.17.
packet send out to 0015af66cba4 through wireless2
****** 47536.0: <Trust/wireless2> packet received [40]******
ipid = 59104(e6e0), @02286b94
packet passed sanity check.
flow_decap_vector IPv4 process
wireless2:20.1.1.1/25420->74.125.103.17/80,6<Root>
no session found
flow_first_sanity_check: in <wireless2>, out <N/A>
**** jump to packet:74.125.103.17->20.1.1.1
skipping pre-frag
no more encapping needed
send out through normal path.
flow_ip_send: d0ac:74.125.103.17->20.1.1.1,6 => wireless2(40) flag 0x0, vlan 0
no l2info for packet.
no route for packet
search route to (null, 0.0.0.0->20.1.1.1) in vr trust-vr for vsd-0/flag-2000/ifp-wireless2
[ Dest] 5.route 20.1.1.1->20.1.1.1, to wireless2
route to 20.1.1.1
arp entry found for 20.1.1.1 mac 001b77c7a58b
packet send out to 001b77c7a58b through wireless2
**** pak processing end.
packet dropped, first pak not sync
****** 47536.0: <Trust/wireless2> packet received [40]******
ipid = 59110(e6e6), @02288094
packet passed sanity check.
flow_decap_vector IPv4 process
wireless2:20.1.1.1/25420->74.125.103.17/80,6, 5004(rst)<Root>
no session found
flow_first_sanity_check: in <wireless2>, out <N/A>
packet dropped, first pak not sync
****** 47536.0: <Trust/wireless2> packet received [40]******
ipid = 59111(e6e7), @02288e94
packet passed sanity check.
flow_decap_vector IPv4 process
wireless2:20.1.1.1/25420->74.125.103.17/80,6, 5004(rst)<Root>
no session found
flow_first_sanity_check: in <wireless2>, out <N/A>
packet dropped, first pak not sync
****** 47536.0: <Trust/wireless2> packet received [40]******
Can anyone tell me what's happening here? Why is the session information being removed? It's just standard port 80 traffic. There are no long gaps that would cause the session information to be removed.
I must have something configured wrongly?
As I said, the workaround is to unset the syn check, but I'm not happy to do this until I understand why it's necessary!
Regards,
Tim
12-16-2009 02:55 PM
*bump*
Are there no netscreen guru's that can answer this one?
Cheers,
Tim
07-22-2010 05:23 PM
Bump.
08-15-2010 07:22 PM
Anyone?
08-16-2010 01:02 AM
Hi!
What is written into the traffic log as a session's closure reason when the session is dropped?
I would recommend to repeat these tests in an ethernet segment. The wireless has it's own drawbacks.
Kind regards,
Edouard
P.S. I am on my holiday till 14-th of September.
08-16-2010 06:57 PM
08-17-2010 12:16 AM
Hi!
The point is to find out if it is a wireless problem or a PBR problem.
You should enable logging both on the session start and on the session close. Policy counting would be also not bad. Perhaps the session are dropped after a certain (big) amount of data has been transfered.
Kind regards,
Edouard