PDA

View Full Version : monitoring through VPN



nolan.rumble
2008-04-02, 04:07
Hi,

I have a client which monitors some hosts on the remote end of the VPN as well as the remote gateway's IP. (By monitoring I mean ICMP ping)

Monitoring Host (A) --> CheckPoint FW (B) <- (VPN) -> Cisco ASA (C) --> Remote Host (D)

1st scenario:
Global Properties:
Accept ICMP requests: First
There is also an explicit rule allowing ICMP between (A) and (D) which has a VPN community defined for that rule.

(A) pings (C) and gets response. (traffic goes outside VPN. Implicit rule matched)
(A) pings (D) and gets no response. (Now I know this is because the implied rule gets matched first)

2nd scenario:
Global Properties:
Accept ICMP requests: Before last

(A) pings (D) and gets response.
(A) pings (C) and gets no response. (It seems that the CheckPoint firewall is trying to push the ping packet down the VPN...why it is doing this, I have no clue as there is no rule which defines that traffic to go down the VPN).

VPN Tunnel sharing is setup in both scenarios as:
One VPN tunnel for each pair of hosts. (This is because there is also SMTP traffic traveling down VPN (refer to CheckPoint SecureKnowledge article: sk19423)

VPN properties (not that I think this makes a difference):
Encryption: 3DES
Hash: MD5
IKE Phase 1 lifetime: 480mins
IKE Phase 2 lifetime: 28800seconds.

VPN community:
(B) and (C) are listed.

Notes about VPN:
(D) has a public IP defined on the firewall (C) which is on the same subnet as (C)'s outside interface.

Now any ideas why the CheckPoint would be trying to push the traffic down the VPN when the rules don't explicitly define that traffic to go down the VPN?

Please let me know if any more details are required.

Thanks in advance!

Nolan

MarioL
2008-04-02, 05:07
What are the encryption domains you have configured for C? Both on the Check Point object for the ASA and on the ASA's own config.

In many cases gateways end up being part of the VPN encryption domain, which can cause issues like you are experiencing.

My guess is that the encryption domain that B "has" for C actually includes C's IP and so it's tunneling it.

PS You should use AES if possible, since it will be better than 3DES in all aspects (performance/security).

nolan.rumble
2008-04-03, 02:59
Hi,

The encryption domains are mirror images of one-another and they only allow connectivity between (A) and (D).

(B) or (C) are not mentioned anywhere in the encryption domain other than the defining points for the beginning and end of the VPN tunnel.

My understanding about AES, is that although it's more secure, from an algorithm's point of view, it's a lot more CPU intensive?

One of the other reasons why 3DES is used is because some environments don't cater for AES encryption standard.

Thanks
Nolan

MarioL
2008-04-03, 05:46
AES has better performance than 3DES, but yes some devices don't support AES.
ACE Team - Security, Performance & Privacy : AES Vs. 3DES block ciphers (http://blogs.msdn.com/ace_team/archive/2007/09/07/aes-vs-3des-block-ciphers.aspx)

No clue why it's doing that, you might have to put up more details up, sorry.

nolan.rumble
2008-04-03, 10:43
Hi,

What details would you need to help me? From what I can see, the VPN is pretty much a standard VPN configuration?

Rule 6
Source: (A)
Destination: (C)
VPN: Any traffic
Service: ICMP
Action: ACCEPT

Rule 7
Source: (A)
Destination: (D)
VPN: MyVPNCommunity
Service: SMTP, icmp
Action ACCEPT

NAT:

Rule 7
Original Packet
Source: (A)
Destination: (D)
Service: Any
Translated Packet
Source: IP address on outside of firewall (E)
Destination: Original
Service: Original

Global Properties:
Options enabled:
Allow bi-directional NAT
Translate destination on client side
Automatic ARP configuration
Translate destination on client side

Tracker is reporting traffic as:
(A) connecting to (C) and hiding behind outside interface of firewall.
(A) connects to (D), it hides behind (E).

Thanks for the help so far! :)

Nolan

melipla
2008-04-03, 15:12
Now any ideas why the CheckPoint would be trying to push the traffic down the VPN when the rules don't explicitly define that traffic to go down the VPN?

From the Help file:

The rules are therefore processed in the following order:

1. Implied Rules defined as first. If an implied rule is First, the implied rule cannot be modified or overwritten in the Security Rule Base because no rules can be placed before it.

2. Explicit Rules 1 through n-1 (assuming n rules) in the Rule Base that are defined by the Administrator.

3. Implied Rules listed as Before Last. Setting a property to Before Last makes it possible to define more detailed rules that will be enforced before this property.

So "Before Last" means that it will attempt to use rules in the rulebase--specifically ones that allow the traffic to traverse the VPN tunnel.

I'd set it to "Before Last" if you want to ping D. In order to ping C as well, there's a few things you can try. I'm guessing the problem is that the VPN domains aren't matching up and C is probably dropping your ping request across the tunnel. A simple way around this is to NAT your ping request to C to be from a source IP that is outside of your VPN domain.

To answer you other question as to "why its being forced down the tunnel", I'm guessing that you're using simplified mode and that your VPN column for your rule is set to "Any connections, whether Clear or Encrypted". The gateway will automatically encrypt the icmp because its to an IP it has a vpn tunnel with.

HTH

nolan.rumble
2008-04-04, 02:50
Hi,



So "Before Last" means that it will attempt to use rules in the rulebase--specifically ones that allow the traffic to traverse the VPN tunnel.


It is currently set to "Before Last".



I'd set it to "Before Last" if you want to ping D. In order to ping C as well, there's a few things you can try. I'm guessing the problem is that the VPN domains aren't matching up and C is probably dropping your ping request across the tunnel. A simple way around this is to NAT your ping request to C to be from a source IP that is outside of your VPN domain.


I'll try that, but not sure if it's going to work or not, because (B) or (C) don't belong to the VPN domain other than me defining them as part of the VPN community.

I've seen the access-lists for (C) and they're essentially mirror images of what I have in my rule base. There's a rule on (C)'s access-lists which allows anyone on the internet to ping (C).

(Just a side note, if I SSH to (B) and try and ping (C), I still get no response from (C).)

The monitoring solution works as follows:
(A) pings (C) to ensure that the remote gateway is up. (Outside VPN)
(A) pings (D) to ensure the remote computer is up. (Inside VPN)
(A) connects to (D) on TCP port 25 to ensure remote service is listening and receiving connections. (Inside VPN)

Just to give you an idea, when (A) connects to (D), (A) is natted behind an IP say: 196.6.6.6.
when (A) connects to (C), it's natted behind 196.6.6.1 ((B)'s outside IP address)

Thanks for your help so far! :)

Nolan

MarioL
2008-04-04, 06:06
Why are you NATting traffic that is part of a VPN tunnel? You don't need to.

nolan.rumble
2008-04-04, 06:10
Client's requirements. I don't unfortunately manage both VPN-terminating devices and because of that the client requests that the 3rd party know nothing about their internal networks.

MarioL
2008-04-04, 09:57
Can you do both tests you did on the first post (scenario 1 and 2) and maybe show us the resulting logs? I'm still all out of ideas.