topic Re: pix vpn tunnel + nat in Network Security

pix vpn tunnel + nat

zulqurnain — Mon, 11 Mar 2019 09:27:45 GMT

Hello,

i have been trying to work out this problem since more then two weeks now, but all my efforts are going in vain.

we 've a vpn tunnel established with our partner and working perfectly, now we 've been asked for the following

1. this partner will connect to our network through this vpn tunnel

2. onces inside our network they will connect to our other partner using our network, who is directly connected to us,

although the second partner router which is inside our premises is only allowing few IP's from our internal network.

3. since due to security we connects to first partner using pre-defined Private Range IP Addresses ( i mean we do nat on

our pix from internal IP Addresses to this pre-defined ip addresses) e.g. our network 192.168.1.0 255.255.255.0

and pre-defined VPN Natted IP Address we use 10.10.60.0-25 netmask 255.255.255.0

4. This time "they" will try to establish a connection on IP Address 10.10.60.20 through our firewall to second partner

as following

1st partner server ----- pix ---- internal router ----- 2nd partner router ----- 2nd partner server (different subnet) 172.16.10.2

5. At this point in our pix we 've to change IP Addresses like following to make sure that first partner connects to second

partner transparently meaning to second partner it will look like the traffic is coming from us instead of any other.

172.18.20.21(1st partner source IP) ------------- 192.168.1.200(our internal LAN IP, known to 2nd partner router to allow traffic

10.10.60.20 (1st partner destination IP) ---------- 172.16.10.2 (2nd partner server ip, actually destination for 1st partner)

for all above mentioned case i 've tried do the following on pix but apperantly like i said all went in vain.

1. global (outside) 50 10.10.60.20

nat (inside) 50 172.16.10.2

2. static (inside,outside) 10.10.60.20 192.168.1.200 netmask 255.255.255.255

access-list VPN-PartnerOne permit ip host 10.10.60.20 host 172.18.20.21

Now i am trying this

nat (outside) 1 10.10.60.20 255.255.255.0 outside

global (inside) 1 192.168.1.200

route inside 172.16.10.0 255.255.255.255 192.168.1.100 (our internal router)

this statement will tell our pix that 172.16.10.0 is trusted network and will now where to route packets

Re: pix vpn tunnel + nat

zulqurnain — Thu, 01 Feb 2007 20:54:12 GMT

hello,

little guidance and help from you experts would really great.

Re: pix vpn tunnel + nat

acomiskey — Thu, 01 Feb 2007 21:02:55 GMT

So, if I understand correctly, you are attempting to make Partner 1 appear as if it is on your inside network 192.168.1.0. Is this correct? Why doesn't partner 2 just allow their subnet?

Re: pix vpn tunnel + nat

zulqurnain — Thu, 01 Feb 2007 21:13:25 GMT

hello,

Yes, that's correct.

Due to security issue's partner 2 does not want to do that and also other implications with management. therefore, this is the best possible solution we have to make.

Re: pix vpn tunnel + nat

zulqurnain — Fri, 02 Feb 2007 04:44:14 GMT

hello,

shading a little light on the case would be really helpfull

Re: pix vpn tunnel + nat

zulqurnain — Fri, 02 Feb 2007 10:23:02 GMT

hello,

i don't believe this, no replies from any person. atleast one can say it's not possible.

Re: pix vpn tunnel + nat

zulqurnain — Fri, 02 Feb 2007 17:36:20 GMT

hello,

any body out there

Re: pix vpn tunnel + nat

Jon Marshall — Fri, 02 Feb 2007 18:11:00 GMT

To translate first partners ip address in your above example

static (outside,inside) 192.168.1.200 172.18.20.21 netmask 255.255.255.255

You need to make sure that 192.168.1.200 will be routed back to your pix when traffic returns from the 2nd partner to the first partner.

for the server translation

static (inside,outside) 10.10.60.20 172.16.10.2 netmask 255.255.255.255

Yes you will need the route on the pix for the 172.16.10.0/24 network.

your crypto access-list VPN-PartnerOne is correct.

HTH

Jon

Re: pix vpn tunnel + nat

zulqurnain — Fri, 02 Feb 2007 18:59:16 GMT

hello jon,

thanks alot for the reply. as for the route i believe what i wrote is also correct ofcourse otherwise i will work it out, but i though i should take the advice

Re: pix vpn tunnel + nat

Jon Marshall — Fri, 02 Feb 2007 21:23:44 GMT

You need to take care of two routing issues:

Your pix needs to be able to route to 172.16.10.2. It looks like you have this correct in your post.

Your internal router needs to know that 192.168.1.200 (which is the Natted partner 1 ip address ) is to be routed back to the pix.

That should do it

Jon

Re: pix vpn tunnel + nat

zulqurnain — Sat, 03 Feb 2007 09:11:51 GMT

hello,

i tried your steps, but i guess something is still not right, as in my syslog from pix i am receving this messages. *log is attached

i configured like below

static (outside,inside) 192.168.1.200 172.18.20.21 netmask 255.255.255.255

static (inside,outside) 10.10.60.20 172.16.10.2 netmask 255.255.255.255

access-list Partner_One permit ip host 10.10.60.20 host 172.18.20.21

route inside 172.16.10.0 255.255.255.255 172.20.4.100

as you we will see in the log that after a while i get SYN_TIMEOUT message appearing. can't understand why?

Re: pix vpn tunnel + nat

Jon Marshall — Sat, 03 Feb 2007 16:21:40 GMT

I thought 192.168.1.100 was your internal router. Does the pix know how to get to 172.20.4.100 ?

Unfortunately i don't have excel on this laptop so i will look on Monday at work.

What you can do is on the inside interface of your pix

debug packet inside dst 172.16.10.2

debug packet inside src 172.16.10.2

This will show you whether everything is flowing through the pix and into your internal network.

Jon

Re: pix vpn tunnel + nat

zulqurnain — Sun, 04 Feb 2007 04:26:43 GMT

hello jon,

actually i made a silly mistake, i.e. while writing the config on the notepad just before copy pasting on to the pix telnet, by mistake i wrote 192.168.11.100. but later while examining the config i found my own dumb mistake. anyways, it worked after i changed it to what it should 've been.

Thanks alot for your help & support.