Gateway generating unwanted traffic to a destination server

[Arun_Kumar_S]

Hello,

I have the following query:

Scenario:
Gateway IP: X.Y.Z.Q
Server IP: A.B.C.D (on cloud)
The server is accessed by internal users on port 8080.
The gateway is also generating unwanted traffic to the destination on port 8080 which is abnormal behavior.

Description:
- HTTPS inspection is enabled on firewall, created a bypass rule with destination but still the traffic is seen.- Traffic is allowed to the destination via implied rules (accept_outgoing rule)
- Traffic capture indicates only oO on external interface.
- Lot of connections can be seen initiated with wstlsd

tcp 0 91 X.Y.Z.Q:60158 A.B.C.D:8080 ESTABLISHED 12214/wstlsd
tcp 0 1 X.Y.Z.Q:59375 A.B.C.D:8080 SYN_SENT 20101/wstlsd
tcp 0 91 X.Y.Z.Q:60332 A.B.C.D:8080 ESTABLISHED 12214/wstlsd
tcp 0 1 X.Y.Z.Q:50854 A.B.C.D:8080 SYN_SENT 20101/wstlsd
tcp 0 91 X.Y.Z.Q:38726 A.B.C.D:8080 ESTABLISHED 12214/wstlsd
tcp 0 91 X.Y.Z.Q:53628 A.B.C.D:8080 ESTABLISHED 12214/wstlsd
tcp 0 91 X.Y.Z.Q:43252 A.B.C.D:8080 ESTABLISHED 12214/wstlsd
tcp 0 91 X.Y.Z.Q:47262 A.B.C.D:8080 ESTABLISHED 12214/wstlsd
tcp 0 91 X.Y.Z.Q:62171 A.B.C.D:8080 ESTABLISHED 12214/wstlsd

- Collected WSTLSD debug and observed the following:

[wstlsd] Trying to connect to Host:
[wstlsd] IP Address network order = A.B.C.D
[wstlsd] Port Number network order = 36895

[wstlsd] T_event_do_set: setting brand new socket/type: 199/0
[wstlsd] T_event_do_set: setting brand new socket/type: 199/2
[wstlsd] T_event_do_set: setting brand new socket/type: 199/1
[wstlsd] fwasync_make_connection_e_bindopt_ex: A.B.C.D/8080: dowait is -1 sock is 199
[wstlsd] T_event_do_del: marking for deletion socket/type: 199/1
[wstlsd] fwasync_connect_ex done. user_mode_connection: 0x1707fae0
[wstlsd] ckptls_store_neg_info: storing neg_info 0x15cde818 opaque_id 77625
[wstlsd] cptls_handle_msg: done. msg=HS_CHALLENGE_PARTY
[wstlsd] cptlsd_trap_handler_multik: trap processing took 0.000104 seconds.
[wstlsd] cptlsd_trap_handler_multik: called dlen 96, type 2
[wstlsd] CptlUrlf::HandleTrap: _len 96 _instance =1
[wstlsd] CptlUrlf::HandleTrap: not urlf ssl trap.
[wstlsd] cptls_urlf_trap_cb: it is not ssl urlf trap.
[wstlsd] cptlsd_trap_handler_multik: called from kernel instance 1.
[wstlsd] cptls_handle_msg: called. msg=HS_CHALLENGE_PARTY
[wstlsd] cptls_handle_msg: kernel_instance: 1

Not sure why this traffic is generated, it would be great if someone has a justification for the same.

Thanks and Regards,
Arun Kumar S
Network Security Engineer
QOS Technology Pvt Ltd, Bengaluru

[Victor_MR]

The wstlsd handles SSL handshake for HTTPS Inspected connections.

Are you running the Check Point Gateway as a proxy?

Another idea, maybe it is the HTTPS probe bypass mechanism?

I don't think they're 'unwanted' connections, but just a regular behavior we have to understand.

[Arun_Kumar_S]

Hey Victor,

SG is not configured as proxy.
Probe bypass is enabled, does it cause this behavior?

Thanks!
Arun

[PhoneBoy]

You may want to open a TAC case but it seems reasonable that Probe Bypass is causing this traffic.

[Arun_Kumar_S]

Hi, Thanks for your response.

I can block the relevant traffic by creating a rule. I do not wish to open a TAC case but I am curious to know why Probe Bypass would generate such traffic.

[Jerry]

I'd definitely recommend you to utilize TAC involvement - that behaviors aren't normal and I'd not hesitate a minute to do that.
Port listening on the server has nothing to do with the SG unless you proxy arp his IP (by mistake) hence I believe you really do not create a clean-up rule for "scrubbing" that flow (involving resources and effort of you SG") but instead let TAC know. They will help you not only to understand but to narrow what exactly is causing it in your environment.

Cheers