VPN- R55 NAT issue

[rn4it]

We have setup a VPN tunnel from our live network into our testlab, this is to allow access into a lab area which other then the internet physically separated. Here's the issue, I attempt the RDP (XP's Remote Desktop) to a server in the testlab. I see the session encrytped to the testlab servers address on the live FW. Then on the testlab firewall I see the testlab server being decrypted and NAT'd to the actual address. This is done because our live and test environments are identical. My RDP seesion times out, what's weird, is that from the testlab firewall I can RDP to the testlab server. I've checked routes, and they are ok, I'm though there was a arp issue, so I used the automatic NAT and Arp options in the global properties.

any ideas?

 

[rn4it]

I've done somemore trouble shooting, both FW's are on the same subnet for their Public IP's. I've tried VPN with simplied and traditional mode. However, if I remove the tunnel and just go though the internet it works. Any ideas?

 

[ChrisAC]

If doing this through a VPN using global IP addresses and NAT, make sure that the global object with the real IP is also in the encryption domain of the firewall otherwise the VPN will not work.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[rn4it]

Thanks Chris, this is where it get weird, the PC I'm attempting to RDP to is receiving the syn packet and is sending the syn-awk. However, it doesn't seem to be coming back through the tunnel. I've run fw monitor, and seen these packets, but on our production FW is not seeing them. I've gone through the security and NAT rules, encryption domains, encrypt key a few times now. I wouldn't mind it if there was an error msg in the log files, but nothing. It is a Win2003 server, know of any weirdness there? thanks

 

[ChrisAC]

That is strange. To be honest I couldn't tell you why that is providing that the encryption domain and VPN settings are correct on BOTH ends. If it just RDP or other ports as well? Can you ping across the VPN?

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[rn4it]

Nope, I'm going to look at it again, during the weekend. Maybe fresh eyes will help. thanks

 

[shaggerTM]

I am a little confused by the original post, so I'll try to describe what you *should* be doing rather than trying to fix your original statement per-se.

Let's start with some myths and try to clear the air a little. There is no relationship between VPNs, NAT'ing and ARP'ing. It is quite possible that you need to use more than one of these functions to solve a problem, but in particular please note that there is absolutely NO connection between NAT and ARP.

How can I say such a controversial thing ? Because it's true, and I'll explain how in a moment. Before you read any further, you may wish to throw away all you learned on the Check Point CCSA/CCSE courses about NAT'ing and ARP'ing - all the examples are contrived and seldom explained by the instructor.

Now.. open your mind, connect to the force... and watch. (If you already understand this stuff, then I apologise !)

ARP: This is a routing trick that we use to get one IP device to send a packet to another device (on the same piece of wire) that DOESN'T actually have the address physically bound to it's (ethernet) interface. The correct term is actually PROXY ARPing, there is also STATIC ARPing which is NOT what we generally use for this kind of work. If you have control of the local routing, there is no NEED to ARP, although you may still elect to use ARPs since it can be less invasive to the infrastructure.

NAT: This is a routing trick that allows us to physically change the IP headers (source address or destination address) of a packet as it passes through our routing point (in this case the Check Point firewall). The only requirement for NAT is that the packet reaches one of our interfaces so that we can process it.

Now, can you see the link ? The link is that they are both routing tricks, and this is what leads people to think that they are inextricably linked. The reality is that you can use either without the other, depending on the requirement. If your routing brings the packet to your firewall, you can NAT it as it passes through, regardless of whether or not you have published a proxy ARP for it.

OK.. now let's consider the scenario with this new revelation in mind.

I have 2 firewalls, with the same internal subnets (a common enough thing with the prevalence of RFC 1918 addressing on internal LANs). How can we then set up a VPN between these 2 identical sites ?

This is the walkthrough.. so rn4it, work with me here step by step and all should be cool ! I'll refer to the firewalls as livesite and DR for my own reference.

I'll assume that you want connections to be able to start on either side of the VPN (rather than just in one direction). I'll also simplistically assume that each site has just a single server that needs to be connected to by the other. You'll need to engage brain in the NAT department, but if you really want me to do the whole job for you you'll need to pay me

The other nasty here, is that this is much easier to do when both firewalls have their own management server. This is because you are screwing with the encryption domains, and although it's not impossible, it's easier to see when you are handling just one side in each rulebase. Also, it won't be much of a DR solution when you lose the only management server on the death of the LiveSite

The common example subnet will be 192.168.1.0/24. The server is on 192.168.1.80 on each side.

1. Select an address subnet for the virtual addresses to be used for servers on the DR site when connecting from the LiveSite side. (example 192.168.200.0/24)

2. Select a different address subnet for the virtual addresses to be used for servers on the LiveSite when connecting from the DR side. (example 192.168.201.0/24)

3. On the Livesite rulebase, create an encryption domain for the LiveSite network containing both the 192.168.1.0/24 network and the 192.168.201.0/24. Create an encryption domain for the DR site for the 192.168.200.0/24 network only.

4. On the DR site rulebase, create an encryption domain for the DR Site network containing both the 192.168.1.0/24 network and the 192.168.200.0/24. Create an encryption domain for the LiveSite for the 192.168.201.0/24 network only.

5. In each security rulebase, create a pair of VPN rules as follows:
ENCDOM-LiveSite -> ENCDOM-DR == ANY == ENCRYPT
ENCDOM-DR -> ENCDOM-LiveSite == ANY == ENCRYPT

*** Now the NAT stuff that will make it all work ***

6. On the LiveSite NAT rulebase, you need 2 rules.
The first rule hides all outbound connections from LiveSite behind a virtual address in the VPN.
ENCDOM-LiveSite -> ENCDOM-DR == ANY || (H)192.168.201.254 -> =Orig == =Orig
The second rule translates incoming connections from DR site to real local destinations.
192.168.200.254 -> 192.168.201.80 == ANY || =Orig -> (S)192.168.1.80 == =Orig

7. On the DR Site NAT rulebase, you need 2 rules.
The first rule hides all outbound connections from DR Site behind a virtual address in the VPN.
ENCDOM-DR -> ENCDOM-LiveSite == ANY || (H)192.168.200.254 -> =Orig == =Orig
The second rule translates incoming connections from LiveSite to real local destinations.
192.168.201.254 -> 192.168.200.80 == ANY || =Orig -> (S)192.168.1.80 == =Orig

*** These rules will need to be ABOVE any outbound hide rules for standard Internet connectivity. ***

NOTES:
=====
This example uses the Traditional Mode for defining the VPN. Using VPN Communities may be convenient in some respects, but ultimately it hides a lot of control and makes certain more advanced configurations more difficult than they need to be.

There is NO ARP for the addresses used to create the virtual bridge.

The NAT rules are created manually to provide control over the NAT rulebase. Automatic NAT rules would not be able to create the same narrowly focussed intent.

The VPN Security rules in this example are deliberately wide, effectively bridging the LANs together. This is NOT RECOMMENDED for a production environment, and I would normally create specific source and destination IP addresses and services, even for VPN rules.





========================================
Find out about what I do for a living at

http://www.ascltd.co.uk

========================================

 

[rn4it]

shaggerTM I appreciate your intent, but I've set up a number of VPN connections in the past. I question and situation is not me having an issue with the 123's of setting up a VPN tunnul. I think if you would have read later on ini my posting you might have noticed that I mentioned I have checked routing, arp, NAT and VPN configurations. I also am able to get the RDP's syn packet to the server I want to Remote Desktop to. If I do a netstat I see this. Therefore, there's no issues getting to the server. However, when the server sends its syn-ack packet (pt2) of the 3part handshake to set up a TCP session, it makes it to it FW, I see this in using fw monitor (CP's sniffer like utility), but I don't see it get back to the internal interface of the other FW. This is where my delema is. If I initiate the RDP session on the test lab side, I see the encrypted packet on the testlab FW, but I don't see a decrypted packet on or dropped packet on the production network. Also if I just use static routes and NAT, no VPN tunnel the RDP works. So, I'm left wondering what's up. I don't typically use Server 2003 at work, we use unix base, so if there's any CP MS weirdness, I not that familair with it. But thanks any way.

 

[rn4it]

Ok I'm not sure exactly what went on, but in working backwards from the fix to the break. It looks like, my initial issue is with simplified mode, not sure what but I don't like it and it doesn't like me. When I tested just using static routes and NAT, which worked, I then converted my rulebase to traditional mode, at which time, I missed removing one of my static routes on the testlabs FW side and phase 2 encryption key on the prodution sides FW.

thanks for your assistance all, it's always the small things in life.

 

[ChrisAC]

It's usually something simple that we overlook ;-)

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[rn4it]

Still, not sure why it didn't work in simplified mode. There was no static route for the internal net of the production net to go to the testlab's FW external interface. oh well check into it, may convert it later into simplied mode and see what happens.

 

[ChrisAC]

I have a couple of firewalls using simplified mode VPN using NAT on those VPN connections and it does work okay so you should be good to go.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************