Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] TCP Proxy behavior for three-way handshake and the rest of the session

0

0

Article ID: KB21780 KB Last Updated: 30 May 2019Version: 2.0
Summary:

TCP Proxy is enabled on the firewall typically when the SYN flood attack threshold is reached. Does it do TCP proxy for the entire session? This article explains the TCP Proxy mechanism in detail with a packet capture done on either side of the firewall.

Solution:

In order to demonstrate the TCP Proxy behavior in the lab, the following settings were configured to trigger the firewall to do TCP Proxy:

syn-flood configuration for interface ethernet0/0
syn flood protection threshold = 1     ------> attack threshold is reduced all the way to just 1, so the one SYN packet itself will trigger TCP proxy on the firewall
syn flood protection timeout value = 50
syn flood protection alarm threshold = 1
syn flood protection queue size = 200
 

Below is the snoop detail output from a SSG when it does the TCP proxy for a typical SSH connection:

Client IP  = 172.22.152.230
Server IP = 7.7.7.10


Client sends SYN packet, received on ethernet0/0:

1164564.0: ethernet0/0(i) len=62:005056ba0006->0010dbffe000/0800
172.22.152.230 -> 7.7.7.10/6
vhl=45, tos=00, id=4032, frag=4000, ttl=128 tlen=48
tcp:ports 6587->22, seq=2701972948, ack=0, flag=7002/SYN
00 10 db ff e0 00 00 50 56 ba 00 06 08 00 45 00 .......PV.....E.
00 30 0f c0 40 00 80 06 97 fa ac 16 98 e6 07 07 .0..@...........
07 0a 19 bb 00 16 a1 0c d5 d4 00 00 00 00 70 02 ..............p.
ff ff 9f 5f 00 00 02 04 05 b4 01 01 04 02 ..._..........


SSG proxies the above connection request and sends SYN/ACK via ethernet0/0 interface towards the client, window size = 0:

1164564.0: ethernet0/0(o) len=54:0010dbffe000->005056ba0006/0800
7.7.7.10 -> 172.22.152.230/6
vhl=45, tos=00, id=19888, frag=0000, ttl=64 tlen=40
tcp:ports 22->6587, seq=179522257, ack=2701972949, flag=5012/SYN/ACK
00 50 56 ba 00 06 00 10 db ff e0 00 08 00 45 00 .PV...........E.
00 28 4d b0 00 00 40 06 da 12 07 07 07 0a ac 16 .(M...@.........
98 e6 00 16 19 bb 0a b3 4a d1 a1 0c d5 d5 50 12 ........J.....P.
00 00 76 8d 00 00 ..v...


Client sends third packet to complete the TCP handshake with the SSG:

1164564.0: ethernet0/0(i) len=60:005056ba0006->0010dbffe000/0800
172.22.152.230 -> 7.7.7.10/6
vhl=45, tos=00, id=4033, frag=4000, ttl=128 tlen=40
tcp:ports 6587->22, seq=2701972949, ack=179522258, flag=5010/ACK
00 10 db ff e0 00 00 50 56 ba 00 06 08 00 45 00 .......PV.....E.
00 28 0f c1 40 00 80 06 98 01 ac 16 98 e6 07 07 .(..@...........
07 0a 19 bb 00 16 a1 0c d5 d5 0a b3 4a d2 50 10 ............J.P.
ff ff 76 8e 00 00 00 00 00 00 00 00 ..v.........


SSG now sends the SYN packet on behalf of the client towards the server, using the same sequence number, seq=2701972949, that was sent by client:

1164564.0: ethernet0/1(o) len=54:0010dbffe050->005056ba000f/0800
172.22.152.230 -> 7.7.7.10/6
vhl=45, tos=00, id=4033, frag=4000, ttl=127 tlen=44
tcp:ports 6587->22, seq=2701972949, ack=0, flag=6002/SYN
00 50 56 ba 00 0f 00 10 db ff e0 50 08 00 45 00 .PV........P..E.
00 2c 0f c1 40 00 7f 06 98 fd ac 16 98 e6 07 07 .,..@...........
07 0a 19 bb 00 16 a1 0c d5 d5 00 00 00 00 60 02 ..............`.
ff ff b4 65 00 00 ...e..


Server responds to the firewall with it's own sequence number and informs it's window size as 65535:

1164564.0: ethernet0/1(i) len=60:005056ba000f->0010dbffe050/0800
7.7.7.10 -> 172.22.152.230/6
vhl=45, tos=00, id=17427, frag=4000, ttl=128 tlen=44
tcp:ports 22->6587, seq=1553675991, ack=2701972950, flag=6012/SYN/ACK
00 10 db ff e0 50 00 50 56 ba 00 0f 08 00 45 00 .....P.PV.....E.
00 2c 44 13 40 00 80 06 63 ab 07 07 07 0a ac 16 .,D.@...c.......
98 e6 00 16 19 bb 5c 9b 36 d7 a1 0c d5 d6 60 12 ......\.6.....`.
ff ff 20 e2 00 00 02 04 05 b4 00 00 ............


Firewall now sends the client an ACK packet with the windows size of the server as 65535:

1164564.0: ethernet0/0(o) len=54:0010dbffe000->005056ba0006/0800
7.7.7.10 -> 172.22.152.230/6
vhl=45, tos=00, id=15134, frag=0000, ttl=64 tlen=40
tcp:ports 22->6587, seq=179522258, ack=2701972949, flag=5010/ACK
00 50 56 ba 00 06 00 10 db ff e0 00 08 00 45 00 .PV...........E.
00 28 3b 1e 00 00 40 06 ec a4 07 07 07 0a ac 16 .(;...@.........
98 e6 00 16 19 bb 0a b3 4a d2 a1 0c d5 d5 50 10 ........J.....P.
ff ff 76 8e 00 00 ..v...


SSG also sends the ACK packets towards the server to maintain the connection:

1164564.0: ethernet0/1(o) len=54:0010dbffe050->005056ba000f/0800
172.22.152.230 -> 7.7.7.10/6
vhl=45, tos=00, id=20013, frag=0000, ttl=64 tlen=40
tcp:ports 6587->22, seq=2701972950, ack=1553675992, flag=5010/ACK
00 50 56 ba 00 0f 00 10 db ff e0 50 08 00 45 00 .PV........P..E.
00 28 4e 2d 00 00 40 06 d9 95 ac 16 98 e6 07 07 .(N-..@.........
07 0a 19 bb 00 16 a1 0c d5 d6 5c 9b 36 d8 50 10 ..........\.6.P.
ff ff 38 9f 00 00 ..8...

After the three-way handshake, the firewall continues to do the TCP Proxy and translate the sequence numbers, keeping track of the Sequence and ACK from both the client and server.

The following snoop output shows packets on the ingress and egress side with different Sequence and ACK numbers.
1164565.0: ethernet0/1(i) len=72:005056ba000f->0010dbffe050/0800
7.7.7.10 -> 172.22.152.230/6
vhl=45, tos=00, id=17428, frag=4000, ttl=128 tlen=58
tcp:ports 22->6587, seq=1553675992, ack=2701972950, flag=5018/ACK
00 10 db ff e0 50 00 50 56 ba 00 0f 08 00 45 00 .....P.PV.....E.
00 3a 44 14 40 00 80 06 63 9c 07 07 07 0a ac 16 .:D.@...c.......
98 e6 00 16 19 bb 5c 9b 36 d8 a1 0c d5 d6 50 18 ......\.6.....P.
ff ff 72 ed 00 00 53 53 48 2d 32 2e 30 2d 63 72 ..r...SSH-2.0-cr
79 70 74 6c 69 62 0d 0a yptlib..


1164565.0: ethernet0/0(o) len=72:0010dbffe000->005056ba0006/0800
7.7.7.10 -> 172.22.152.230/6
vhl=45, tos=00, id=17428, frag=4000, ttl=127 tlen=58
tcp:ports 22->6587, seq=179522258, ack=2701972949, flag=5018/ACK
00 50 56 ba 00 06 00 10 db ff e0 00 08 00 45 00 .PV...........E.
00 3a 44 14 40 00 7f 06 64 9c 07 07 07 0a ac 16 .:D.@...d.......
98 e6 00 16 19 bb 0a b3 4a d2 a1 0c d5 d5 50 18 ........J.....P.
ff ff b0 dc 00 00 53 53 48 2d 32 2e 30 2d 63 72 ......SSH-2.0-cr
79 70 74 6c 69 62 0d 0a yptlib..

1164565.0: ethernet0/0(i) len=60:005056ba0006->0010dbffe000/0800
172.22.152.230 -> 7.7.7.10/6
vhl=45, tos=00, id=4034, frag=4000, ttl=128 tlen=40
tcp:ports 6587->22, seq=2701972949, ack=179522276, flag=5010/ACK
00 10 db ff e0 00 00 50 56 ba 00 06 08 00 45 00 .......PV.....E.
00 28 0f c2 40 00 80 06 98 00 ac 16 98 e6 07 07 .(..@...........
07 0a 19 bb 00 16 a1 0c d5 d5 0a b3 4a e4 50 10 ............J.P.
ff ed 76 8e 00 00 00 00 00 00 00 00 ..v.........

1164565.0: ethernet0/1(o) len=54:0010dbffe050->005056ba000f/0800
172.22.152.230 -> 7.7.7.10/6
vhl=45, tos=00, id=4034, frag=4000, ttl=127 tlen=40
tcp:ports 6587->22, seq=2701972950, ack=1553676010, flag=5010/ACK
00 50 56 ba 00 0f 00 10 db ff e0 50 08 00 45 00 .PV........P..E.
00 28 0f c2 40 00 7f 06 99 00 ac 16 98 e6 07 07 .(..@...........
07 0a 19 bb 00 16 a1 0c d5 d6 5c 9b 36 ea 50 10 ..........\.6.P.
ff ed 38 9f 00 00 ..8...


Debug flow basic shows the following:
FW-> get db st
****** 00080.0: <Untrust/ethernet0/0> packet received [48]******
ipid = 6110(17de), @03ccdc90
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet0/0:172.22.152.230/6756->7.7.7.10/22,6<Root>
no session found
flow_first_sanity_check: in <ethernet0/0>, out <N/A>
chose interface ethernet0/0 as incoming nat if.
flow_first_routing: in <ethernet0/0>, out <N/A>
search route to (ethernet0/0, 172.22.152.230->7.7.7.10) in vr trust-vr for vsd-0/flag-0/ifp-null
cached route 0 for 7.7.7.10
add route 3 for 7.7.7.10 to route cache table
[ Dest] 3.route 7.7.7.10->7.7.7.10, to ethernet0/1
routed (x_dst_ip 7.7.7.10) from ethernet0/0 (ethernet0/0 in 0) to ethernet0/1
policy search from zone 1-> zone 2
policy_flow_search policy search nat_crt from zone 1-> zone 2
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 7.7.7.10, port 22, proto 6)
No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 2/1/0x9
Permitted by policy 2
No src xlate choose interface ethernet0/1 as outgoing phy if
check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp ethernet0/1
vsd 0 is active
no loop on ifp ethernet0/1.
session application type 22, name None, nas_id 0, timeout 1800sec
ALG vector is not attached
service lookup identified service 0.
flow_first_final_check: in <ethernet0/0>, out <ethernet0/1>
install vector flow_nsrp_fwd_vector
install vector flow_ttl_vector
install vector flow_tcp_syn_mss_vector
install vector flow_tcp_proxy_vector
install vector flow_tcp_seq_vector
install vector flow_tcp_fin_vector
install vector flow_l2prepare_xlate_vector
install vector flow_frag_list_vector
install vector flow_fragging_vector
install vector flow_send_shape_vector
install vector NULL
create new vector list 133-304fce4.
Session (id:16061) created for first pak 133
flow_first_install_session======>
handle cleartext reverse route
search route to (ethernet0/1, 7.7.7.10->172.22.152.230) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/0
cached route 0 for 172.22.152.230
add route 1 for 172.22.152.230 to route cache table
[ Dest] 1.route 172.22.152.230->172.22.152.230, to ethernet0/0
route to 172.22.152.230
cached arp entry with MAC 000000000000 for 172.22.152.230
add arp entry with MAC 005056ba0006 for 172.22.152.230 to cache table
arp entry found for 172.22.152.230
ifp2 ethernet0/0, out_ifp ethernet0/0, flag 00800801, tunnel ffffffff, rc 1
flow got session.
flow session id 16061
flow_main_body_vector in ifp ethernet0/0 out ifp ethernet0/1
flow vector index 0x133, vector addr 0x304fce4, orig vector 0x304fce4   -----------> 0x133 is the vector for TCP proxy
route to 7.7.7.10
cached arp entry with MAC 000000000000 for 7.7.7.10
add arp entry with MAC 000000000000 for 7.7.7.10 to cache table
wait for arp rsp for 7.7.7.10
ifp2 ethernet0/1, out_ifp ethernet0/1, flag 00000800, tunnel ffffffff, rc 0
vsd 0 is active
tcp proxy processing...

**** jump to packet:7.7.7.10->172.22.152.230
skipping pre-frag
no more encapping needed
packet already has mac 005056ba0006 send out to ethernet0/0 directly send flag 0
packet send out to 005056ba0006 through ethernet0/0
**** pak processing end.

 
In the debug flow you identify by different messages whether the firewall is doing normal processing or TCP processing
 

The vector numbers will vary between different platforms:


0x133 means that TCP proxy is enabled on the session (TCP proxy vector in SSG)

flow vector index 0x133, vector addr 0x304fce4, orig vector 0x304fce4


0x123 means normal, without TCP Proxy  (Normal TCP processing vector in SSG)

flow vector index 0x123, vector addr 0x3053dc4, orig vector 0x3053dc4
Modification History:
2019-05-30: Minor, non-technical update.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search