This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
ABOUT CHECKMATES CYBER SECURITY COMMUNITY & FAQ
Create a Post
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Are you a member of CheckMates?

×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
Vladimir
Champion
Champion
‎2017-09-27 03:13 PM
Jump to solution

Inconsistent behavior of vSEC in AWS

Weirdest thing:

Immediately after policy load, test traffic succeeding.

Few minutes later, no go.

There is NO Dynamic routing involved.

Lab Setup

Good traffic immediately after policy load:


Client session:

[vladimir@centos7 ~]$ curl http://34.235.192.92/hello.html

<html><h1>Hello from Amazon EC201</h1></html>

[vladimir@centos7 ~]$


vSEC:

[Expert@vSEC01:0]# fw monitor -e 'accept port(80);'
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_1] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=27946
TCP: 19023 -> 80 .S.... seq=e03cd91b ack=00000000
[vs_0][fw_1] eth0:I[60]: 24.89.129.101 -> 10.255.255.210 (TCP) len=60 id=27946
TCP: 19023 -> 80 .S.... seq=e03cd91b ack=00000000
[vs_0][fw_1] eth1:o[60]: 24.89.129.101 -> 10.255.255.210 (TCP) len=60 id=27946
TCP: 19023 -> 80 .S.... seq=e03cd91b ack=00000000
[vs_0][fw_1] eth1:O[60]: 24.89.129.101 -> 10.255.255.210 (TCP) len=60 id=27946
TCP: 19023 -> 80 .S.... seq=e03cd91b ack=00000000
[vs_0][fw_1] eth1:i[60]: 10.255.255.210 -> 24.89.129.101 (TCP) len=60 id=0
TCP: 80 -> 19023 .S..A. seq=8cd9c86d ack=e03cd91c
[vs_0][fw_1] eth1:I[60]: 10.255.255.210 -> 24.89.129.101 (TCP) len=60 id=0
TCP: 80 -> 19023 .S..A. seq=8cd9c86d ack=e03cd91c
[vs_0][fw_1] eth0:o[60]: 10.255.255.210 -> 24.89.129.101 (TCP) len=60 id=0
TCP: 80 -> 19023 .S..A. seq=8cd9c86d ack=e03cd91c
[vs_0][fw_1] eth0:O[60]: 10.255.255.23 -> 24.89.129.101 (TCP) len=60 id=0
TCP: 80 -> 19023 .S..A. seq=8cd9c86d ack=e03cd91c
[vs_0][fw_1] eth0:i[52]: 24.89.129.101 -> 10.255.255.23 (TCP) len=52 id=27947
TCP: 19023 -> 80 ....A. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth0:I[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27947
TCP: 19023 -> 80 ....A. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth1:o[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27947
TCP: 19023 -> 80 ....A. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth1:O[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27947
TCP: 19023 -> 80 ....A. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth0:i[139]: 24.89.129.101 -> 10.255.255.23 (TCP) len=139 id=27948
TCP: 19023 -> 80 ...PA. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth0:I[139]: 24.89.129.101 -> 10.255.255.210 (TCP) len=139 id=27948
TCP: 19023 -> 80 ...PA. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth1:o[139]: 24.89.129.101 -> 10.255.255.210 (TCP) len=139 id=27948
TCP: 19023 -> 80 ...PA. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth1:O[139]: 24.89.129.101 -> 10.255.255.210 (TCP) len=139 id=27948
TCP: 19023 -> 80 ...PA. seq=e03cd91c ack=8cd9c86e
[vs_0][fw_1] eth1:i[52]: 10.255.255.210 -> 24.89.129.101 (TCP) len=52 id=36280
TCP: 80 -> 19023 ....A. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth1:I[52]: 10.255.255.210 -> 24.89.129.101 (TCP) len=52 id=36280
TCP: 80 -> 19023 ....A. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth0:o[52]: 10.255.255.210 -> 24.89.129.101 (TCP) len=52 id=36280
TCP: 80 -> 19023 ....A. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth0:O[52]: 10.255.255.23 -> 24.89.129.101 (TCP) len=52 id=36280
TCP: 80 -> 19023 ....A. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth1:i[371]: 10.255.255.210 -> 24.89.129.101 (TCP) len=371 id=36281
TCP: 80 -> 19023 ...PA. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth1:I[371]: 10.255.255.210 -> 24.89.129.101 (TCP) len=371 id=36281
TCP: 80 -> 19023 ...PA. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth0:o[371]: 10.255.255.210 -> 24.89.129.101 (TCP) len=371 id=36281
TCP: 80 -> 19023 ...PA. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth0:O[371]: 10.255.255.23 -> 24.89.129.101 (TCP) len=371 id=36281
TCP: 80 -> 19023 ...PA. seq=8cd9c86e ack=e03cd973
[vs_0][fw_1] eth0:i[52]: 24.89.129.101 -> 10.255.255.23 (TCP) len=52 id=27949
TCP: 19023 -> 80 ....A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth0:I[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27949
TCP: 19023 -> 80 ....A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth1:o[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27949
TCP: 19023 -> 80 ....A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth1:O[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27949
TCP: 19023 -> 80 ....A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth0:i[52]: 24.89.129.101 -> 10.255.255.23 (TCP) len=52 id=27950
TCP: 19023 -> 80 F...A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth0:I[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27950
TCP: 19023 -> 80 F...A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth1:o[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27950
TCP: 19023 -> 80 F...A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth1:O[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27950
TCP: 19023 -> 80 F...A. seq=e03cd973 ack=8cd9c9ad
[vs_0][fw_1] eth1:i[52]: 10.255.255.210 -> 24.89.129.101 (TCP) len=52 id=36282
TCP: 80 -> 19023 F...A. seq=8cd9c9ad ack=e03cd974
[vs_0][fw_1] eth1:I[52]: 10.255.255.210 -> 24.89.129.101 (TCP) len=52 id=36282
TCP: 80 -> 19023 F...A. seq=8cd9c9ad ack=e03cd974
[vs_0][fw_1] eth0:o[52]: 10.255.255.210 -> 24.89.129.101 (TCP) len=52 id=36282
TCP: 80 -> 19023 F...A. seq=8cd9c9ad ack=e03cd974
[vs_0][fw_1] eth0:O[52]: 10.255.255.23 -> 24.89.129.101 (TCP) len=52 id=36282
TCP: 80 -> 19023 F...A. seq=8cd9c9ad ack=e03cd974
[vs_0][fw_1] eth0:i[52]: 24.89.129.101 -> 10.255.255.23 (TCP) len=52 id=27951
TCP: 19023 -> 80 ....A. seq=e03cd974 ack=8cd9c9ae
[vs_0][fw_1] eth0:I[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27951
TCP: 19023 -> 80 ....A. seq=e03cd974 ack=8cd9c9ae
[vs_0][fw_1] eth1:o[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27951
TCP: 19023 -> 80 ....A. seq=e03cd974 ack=8cd9c9ae
[vs_0][fw_1] eth1:O[52]: 24.89.129.101 -> 10.255.255.210 (TCP) len=52 id=27951
TCP: 19023 -> 80 ....A. seq=e03cd974 ack=8cd9c9ae
monitor: caught sig 2
monitor: unloading
[Expert@vSEC01:0]#


Web Server on EC2 behind Logical Server:

[ec2-user@ip-10-255-255-210 ~]$ sudo tcpdump -n host 24.89.129.101
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:29:23.086278 IP 24.89.129.101.19023 > 10.255.255.210.http: Flags [S], seq 3762084123, win 29200, options
[mss 1460,sackOK,TS val 169391153 ecr 0,nop,wscale 7], length 0
21:29:23.086307 IP 10.255.255.210.http > 24.89.129.101.19023: Flags [S.], seq 2363082861, ack 3762084124,
win 26847, options [mss 8961,sackOK,TS val 2639313 ecr 169391153,nop,wscale 7], length 0
21:29:23.102856 IP 24.89.129.101.19023 > 10.255.255.210.http: Flags [.], ack 1, win 229, options
[nop,nop,TS val 169391175 ecr 2639313], length 0
21:29:23.106642 IP 24.89.129.101.19023 > 10.255.255.210.http: Flags [P.], seq 1:88, ack 1, win 229, options
[nop,nop,TS val 169391175 ecr 2639313], length 87
21:29:23.106660 IP 10.255.255.210.http > 24.89.129.101.19023: Flags [.], ack 88, win 210, options
[nop,nop,TS val 2639318 ecr 169391175], length 0
21:29:23.106875 IP 10.255.255.210.http > 24.89.129.101.19023: Flags [P.], seq 1:320, ack 88, win 210,
options [nop,nop,TS val 2639318 ecr 169391175], length 319
21:29:23.122734 IP 24.89.129.101.19023 > 10.255.255.210.http: Flags [.], ack 320, win 237, options
[nop,nop,TS val 169391195 ecr 2639318], length 0
21:29:23.124526 IP 24.89.129.101.19023 > 10.255.255.210.http: Flags [F.], seq 88, ack 320, win 237, options
[nop,nop,TS val 169391195 ecr 2639318], length 0
21:29:23.124553 IP 10.255.255.210.http > 24.89.129.101.19023: Flags [F.], seq 320, ack 89, win 210, options
[nop,nop,TS val 2639322 ecr 169391195], length 0
21:29:23.141031 IP 24.89.129.101.19023 > 10.255.255.210.http: Flags [.], ack 321, win 237, options
[nop,nop,TS val 169391213 ecr 2639322], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
[ec2-user@ip-10-255-255-210 ~]$


Few minutes later:


Client session:

[vladimir@centos7 ~]$ curl http://34.235.192.92/hello.html

curl: (7) Failed connect to 34.235.192.92:80; Connection timed out
[vladimir@centos7 ~]$


vSEC:

[Expert@vSEC01:0]# fw monitor -e 'accept port(80);'
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_1] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21286
TCP: 19024 -> 80 .S.... seq=1901a5b5 ack=00000000
[vs_0][fw_0] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21287
TCP: 19024 -> 80 .S.... seq=1901a5b5 ack=00000000
[vs_0][fw_0] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21288
TCP: 19024 -> 80 .S.... seq=1901a5b5 ack=00000000
[vs_0][fw_0] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21289
TCP: 19024 -> 80 .S.... seq=1901a5b5 ack=00000000
[vs_0][fw_0] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21290
TCP: 19024 -> 80 .S.... seq=1901a5b5 ack=00000000
[vs_0][fw_1] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21291
TCP: 19024 -> 80 .S.... seq=1901a5b5 ack=00000000
[vs_0][fw_1] eth0:i[60]: 24.89.129.101 -> 10.255.255.23 (TCP) len=60 id=21292
TCP: 43813 -> 80 .S.... seq=1901a5b5 ack=00000000
^C monitor: caught sig 2
monitor: unloading
[Expert@vSEC01:0]#


Web Server on EC2 behind Logical Server:

[ec2-user@ip-10-255-255-210 ~]$ sudo tcpdump -n host 24.89.129.101
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[ec2-user@ip-10-255-255-210 ~]$

Any ideas?

37 Replies
PhoneBoy
Admin
Admin
‎2017-11-15 11:45 AM
In response to Vladimir
Jump to solution

Logical Servers (aka ConnectControl) have been around for quite some time (pre-NG, I think?) and were initially designed to serve as a load balancer.

Not much development has occurred with this feature in the past several years.

However, we effectively resurrected it with the developments around vSEC in the Public Cloud.

The Domain option for Logical Servers (which sk31162 says is not supported) was repurposed for use in vSEC Public Cloud.

In particular, the name of the Logical Server object is queried against DNS to determine where to send and NAT the traffic.

The group you assign to this Logical Server object needs to be there for the policy to validate, but is otherwise not relevant to the configuration.

This is described here: Supporting internal Elastic Load Balancers (ELB) in Amazon Web Services (AWS) 

I will have sk31162 updated appropriately.

0 Kudos
Iain_King
Collaborator
‎2017-11-15 04:16 PM
Jump to solution

Look, I have a configuration in AWS for a customer in the same scenario in R77.30 which is working and in production. It was not simple.. as the SSL terminated on the FE ELB and then traffic is NAT'd again to the back end ELBs both using logical server objects with domain settings for cross-region distribution.

It required both NAT and PAT in both directions and logical server options.. but it is in production for a large company (it's is a ticketing, sales and reporting system for amusement parks). I am happy to provide more details privately if anyone is interested (I have diagrams I can blank etc NDA).

Is the problem you are having not working in R80.10 only.. ? because this is working in R77.30 I can confirm.

the vSEC license distribution btw is just a script which cpr_util rexec / rcmd bash..  cplic imports. 

0 Kudos
Iain_King
Collaborator
‎2017-11-15 04:24 PM
Jump to solution

Thinking about it, the diagram / configuration may be incomplete.. you may be receiving connections from more front end ELB's than you realize. It might be a good idea to tcpdump for connections destined for the firewall (or wherever the ELB is sending it), The ELB's also do ICMP to the firewalls for up-time determination and default security profiles for the cloud network may prevent the return ICMP from the firewall (this was one problem I experienced which was very difficult to debug and required AWS support involvement).

Cheers,

Iain

0 Kudos
Vladimir
Champion
Champion
‎2017-11-16 06:36 AM
In response to Iain_King
Jump to solution

Iain,

Thanks for your input.

No, the situation described here is exactly as depicted on the diagram.

This was part of the POCs that I have build, some of which do include the ELBs are shown here:

https://community.checkpoint.com/docs/DOC-2301-vsec-deployment-scenarios-in-aws as well as a more complex scenarios including external ELBs, that I have not yet published.

In this particular case, native Logical Server object was used to load balance between web-hosts and was configured according to CP documentation.

As to scenarios utilizing AWS ELBs, these do work as advertised in R80.10.

0 Kudos
PhoneBoy
Admin
Admin
‎2017-11-16 09:44 AM
In response to Vladimir
Jump to solution

We don't officially support ELBs with R80.10 just yet... I know it's in the near-term plans to address this.

0 Kudos
Iain_King
Collaborator
‎2017-11-16 08:59 PM
In response to Vladimir
Jump to solution

Ahh I see!

No worries, I'll have a good look through those deployment scenarios (thanks for the publication btw, it will definitely be helpful for everyone).

Iain

0 Kudos
Vladimir
Champion
Champion
‎2017-12-21 07:28 AM
Jump to solution

Update: The reason for the timeout appears to be related to the ICMP health probe the gateway is running on the target servers. In the absence of ICMP echo request in the Security Group the servers belong to, after one minute Logical Server object deems server as not reachable. If ICMP echo request is permitted, it works without timeout.

I am still waiting for the response from R&D in regards to supported modes of load balancing in AWS using Logical Servers and will update this thread once I receive it.

For now, it was successfully tested using:

Service Type: Other

Server Group: [Simple Group with target servers]

Use persistent server mode: True

Persistency  by server

Balance method: Round trip

Iain_King
Collaborator
‎2018-04-17 04:18 AM
In response to Vladimir
Jump to solution

Yep, we experienced this as well.. very difficult to debug as an integrator without access to the AWS console.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

View All ≫
UPCOMING CLOUDMATES EVENTS
    All CloudMates Events