PIX to PIX site vpn connection continued....

Problem #1
>access-list valobg permit ip 172.28.228.0 255.255.255.0 192.168.0.0 255.255.255.0
>nat (inside) 0 access-list 101
>nat (inside) 2 access-list valobg 0 0

Remove this one:
   no nat (inside) 2 access-list valobg 0 0

add this to define traffic from local LAN to remote LAN, applied to nat 0 along with the traffic for the vpn clients:
   access-list 101 permit ip 172.28.228.0 255.255.255.0 192.168.0.0 255.255.255.0  

but access-list 101 is for our vpn that is setup for users that connect via Cisco VPN Client.

wouldn't I need a second access-list and nat for this site-to-site connection?

Mark

By the way, here is our second site's PIX config, the one we're trying to connect to:


PIX Version 6.3(3)
interface ethernet0 10baset
interface ethernet1 100full
interface ethernet2 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security4
enable password XQBKSUnJ8EqSZUeb encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname pixfirewall
domain-name ciscopix.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list outbound permit tcp any host 207.162.188.200 eq smtp
access-list outbound permit tcp any host 207.162.188.200 eq 3389
access-list outbound permit tcp any host 207.162.188.200 eq www
access-list outbound permit tcp any host 207.162.188.203 eq 3389
access-list inland_nat permit ip any 10.199.1.0 255.255.255.0
access-list inland_nat permit ip any 10.199.2.0 255.255.255.0
access-list inland_nat permit ip any host 10.199.4.50
access-list inland_nat permit ip any host 10.199.4.112
access-list inland_nat permit ip any host 10.199.4.20
access-list inland_match permit ip host 10.199.202.225 10.199.1.0 255.255.255.0
access-list inland_match permit ip host 10.199.202.225 10.199.2.0 255.255.255.0
access-list inland_match permit ip host 10.199.202.225 host 10.199.4.50
access-list inland_match permit ip host 10.199.202.225 host 10.199.4.112
access-list inland_match permit ip host 10.199.202.225 host 10.199.4.20
access-list incyte_match permit ip 192.168.0.0 255.255.255.0 172.28.228.0 255.25
5.255.0
access-list PAML_match permit ip host 192.168.0.7 172.30.0.0 255.255.255.0
access-list PAML_match permit ip host 192.168.0.7 172.30.1.0 255.255.255.0
access-list PAML_match permit ip host 192.168.0.7 host 172.30.3.56
access-list PAML_match permit ip host 192.168.0.7 host 172.30.3.200
access-list PAML_match permit ip host 192.168.0.7 host 172.30.99.99
pager lines 24
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside 207.162.188.202 255.255.255.248
ip address inside 192.168.0.254 255.255.255.0
no ip address intf2
ip audit info action alarm
ip audit attack action alarm
pdm location 192.168.0.2 255.255.255.255 inside
pdm location 192.168.0.4 255.255.255.255 inside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
global (outside) 2 10.199.202.225
nat (inside) 0 access-list PAML_match
nat (inside) 2 access-list inland_nat 0 0
nat (inside) 3 access-list incyte_match 0 0
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 207.162.188.200 192.168.0.2 netmask 255.255.255.255 0 0
static (inside,outside) 207.162.188.203 192.168.0.4 netmask 255.255.255.255 0 0
access-group outbound in interface outside
route outside 0.0.0.0 0.0.0.0 207.162.188.201 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 192.168.0.0 255.255.0.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set esp-3des-md5 esp-3des esp-md5-hmac
crypto ipsec transform-set standard esp-3des esp-md5-hmac
crypto ipsec transform-set chevelle esp-3des esp-md5-hmac
crypto map outisde_map 20 ipsec-isakmp
crypto map outisde_map 20 match address inland_match
crypto map outisde_map 20 set peer 62.148.219.9
crypto map outisde_map 20 set transform-set standard
crypto map outisde_map 30 ipsec-isakmp
crypto map outisde_map 30 match address PAML_match
crypto map outisde_map 30 set peer 204.157.189.161
crypto map outisde_map 30 set transform-set esp-3des-md5
crypto map outisde_map 40 ipsec-isakmp
crypto map outisde_map 40 match address incyte_match
crypto map outisde_map 40 set peer 64.106.169.161
crypto map outisde_map 40 set transform-set chevelle
crypto map outisde_map interface outside
isakmp enable outside
isakmp key ******** address 62.148.219.9 netmask 255.255.255.255
isakmp key ******** address 204.157.189.161 netmask 255.255.255.255
isakmp key ******** address 64.106.169.161 netmask 255.255.255.255
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 1
isakmp policy 20 lifetime 86400
telnet 215.221.98.31 255.255.255.240 outside
telnet 192.168.0.2 255.255.255.255 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 5
console timeout 0
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
terminal width 80
Cryptochecksum:90a3ceafe16311c1392c96c6c9c6da4f
: end
[OK]

Thanks.

Mark

You can have one and only one nat 0, and the acl must contain BOTH the LAN-VPN client traffic and the LAN-LAN traffic.

nat (inside) 0
                 ^ this is a very special designation that means "don't nat"

nat (inside) 2
                 ^ just means yes, nat, but only this traffic (acl). You must have a matching "global (outside) 2"

That's why it's not working for  you.

Same principle on the other side.
Should be:
  >access-list PAML_match permit ip host 192.168.0.7 host 172.30.99.99
add:
    access-list PAML_match permit ip 192.168.0.0 255.255.255.0 172.28.228.0 255.255.255.0
    no nat (inside) 3 access-list incyte_match 0 0

ok, we'll call my first config 'Site A' and second one 'Site B', so we don't get confused (hopefully).

At site B, the PAML stuff works.  That is a different site that Site B connects to.  Site A is the incyte_match stuff.

So wouldn't we still need to nat between Site A and Site B?

When you say you must have a matching "global (outside) 2", what do I need to do there?  Match it to the "nat (inside)..."?

Thanks Irmoore.

Mark

Here's the thing....

You're trying to bypass nat between site B and site A through the VPN tunnel.
You are ALSO already bypassing nat between site B and PAML(C).
You can only have one nat 0 to bypass nat, so the acl must contain both remote subnets.
  example:
   access-list no_nat permit ip <local lan> <mask> <remote A LAN> <mask>
   access-list no_nat permit ip <local lan> <mask> <remote B LAN> <mask>
   access-list no_nat permit ip <local lan> <mask> <remote C LAN> <mask>
   access-list no_nat permit ip <local lan> <mask> <VPN Client POOL> <mask>
  nat (inside) 0 access-list no_nat

Now, you are also defining traffic for each individual VPN tunnel
   access-list vpn_to_siteA permit ip <local lan> <mask> <remote A LAN> <mask>
   access-list vpn_to_siteB permit ip <local lan> <mask> <remote B LAN> <mask>
   access-list vpn_to_siteC permit ip <local lan> <mask> <remote C LAN> <mask>

Now, those -individual- acls can be applied to individual crypto map statements, just like you have them on Site B's config:

crypto map outisde_map 20 ipsec-isakmp
crypto map outisde_map 20 match address vpn_to_siteA

crypto map outisde_map 30 ipsec-isakmp
crypto map outisde_map 30 match address vpn_to_siteB

crypto map outisde_map 40 ipsec-isakmp
crypto map outisde_map 40 match address vpn_to_siteC

crypto map outisde_map interface outside

Ok, I didn't setup Site B's config, so there are still a couple questions.

Can you explain these few lines to me:

access-list inland_nat permit ip any host 10.199.4.20
access-list inland_match permit ip host 10.199.202.225 10.199.1.0 255.255.255.0
access-list inland_match permit ip host 10.199.202.225 10.199.2.0 255.255.255.0
access-list inland_match permit ip host 10.199.202.225 host 10.199.4.50

I think I understand that the first line says to permit any ip's from the local network to access the host 10.199.4.20, which must be an inside address on the other site's (Inland) network.

But I don't understand the next 3 lines.  Are these all inside addresses on Inland's LAN?

Mark

lrmoore has it nailed. let me see if i can help clear it up in another set of words
Currently you have

access-list 101 permit ip 172.28.228.0 255.255.255.0 100.100.100.0 255.255.255.0
access-list valobg permit ip 172.28.228.0 255.255.255.0 192.168.0.0 255.255.255.0
nat (inside) 0 access-list 101
nat (inside) 2 access-list valobg 0 0

Now both these access list need to be under 'no nat' or nat 0. Since there can only be 1 nat 0
You need to make this

access-list 101 permit ip 172.28.228.0 255.255.255.0 100.100.100.0 255.255.255.0
access-list 101 permit ip 172.28.228.0 255.255.255.0 192.168.0.0 255.255.255.0
nat (inside) 0 access-list 101

Now to apply to the crypto map define 2 new access-lists
access-list valobg permit ip 172.28.228.0 255.255.255.0 192.168.0.0 255.255.255.0
and apply this to the crypto map.

Same on the other side. Hope this helps.



On a side note, dont user 100.100.100.X as your remote IP assignments. This is not an internal IP and it is bad practise to give internal hosts internet routable IP addresses. Once solution is to reserve a part on your internal subnet for VPN client hosts. So if you inside subnet is 192.168.0.0, then save 32 address for VPN hosts and assign this to your IP pool. Modify the access-list to match the  pool and mask. This makes routing easy as well.

Only guessing on the config from B

//-- this acl is applied to nat "2" below, with a corresponding global "2"
//-- so to the remote host, everything going out gets nat'd and appears to be coming from host 10.199.202.225

access-list inland_nat permit ip any 10.199.1.0 255.255.255.0
access-list inland_nat permit ip any 10.199.2.0 255.255.255.0
access-list inland_nat permit ip any host 10.199.4.50
<etc>
nat (inside) 2 access-list inland_nat 0 0
global (outside) 2 10.199.202.225

//-- this acl defines the traffic that gets applied to the crypto map, encrypted and forwarded to the correct peer
//-- notice that the source host=global "2" ip
//-- The "inland_match" acl appears identical to "inland_nat" acl, exept the source is the global IP, not the local lan subnet
access-list inland_match permit ip host 10.199.202.225 10.199.1.0 255.255.255.0
access-list inland_match permit ip host 10.199.202.225 10.199.2.0 255.255.255.0
access-list inland_match permit ip host 10.199.202.225 host 10.199.4.50
<etc>

crypto map outisde_map 20 ipsec-isakmp
crypto map outisde_map 20 match address inland_match
crypto map outisde_map 20 set peer 62.148.219.9

Ok, so I guess I need to figure out if I'm going to 'nat' or not between our sites.

Thing is, the other site wants to keep everything seperated, for example, Inland, Paml, and Incyte are 3 different sites, so they wanted to distinguish between them in their configuration.

But, since Paml has the 'nat 0', to add Incyte's ip range to it would mean Incyte's range would have the access-list name of Paml, which would be incorrect as far as keeping the sites seperate.

But it seems that would be the easiest way.

But, if I truely needed to keep them seperate, then I would need 'nat' between them and us (we are incyte, they are valobg --- we are Site A, they are Site B).

hence:    incyte = Site A             valobg = Site B

So would that be the best way to go, to 'nat' between Site A and Site B?

Mark

I highly suggest keeping it as simple as possible and not nat between the sites.
It really will get even more complicated if you try to nat on both sides through the VPN tunnel.

If the other site wants to keep it clean for appearance sake, create a no_nat acl and then 3 separate acls just like we've demonstrated. This still serves the same purpose.

Adding to this comment
-----------------------------------
But, since Paml has the 'nat 0', to add Incyte's ip range to it would mean Incyte's range would have the access-list name of Paml, which would be incorrect as far as keeping the sites seperate.
-----------------------------------

create this
acl 101 incyte .....
acl 101 paml .....
nat (inside) 0 acl 101

This is your nat entry.
As for keeping the sites separate now you create a new acl exactly the same as 101 .....
acl 102 incyte
acl 103 paml
Now apply acl 102 to the crypto map for incyte
apply acl 103 to the crypto map for paml

This way you have 1 nat 0 entry but you keep the traffic separate.

based on your statements a few comments above:

>Now, those -individual- acls can be applied to individual crypto map statements, just like you have them on Site B's config:

Would I still apply the no-nat access-lists to crypto map statements?  Or just the individual ones?

Mark

>Would I still apply the no-nat access-lists to crypto map statements?  Or just the individual ones?
No. That's the whole point.

The no_nat acl only gets applied to nat (inside) 0 access-list no_nat

Each individual acl gets applied to the individual crypto map statements only

>create this
acl 101 incyte .....
acl 101 paml .....
nat (inside) 0 acl 101

So, as long as '101' is first, I can put the word "incyte" after '101 in the first acl, and the word "paml" after the '101' in the second acl and then enter "nat (inside) 0 acl 101" and it will see both as being the same access list name?  

or by saying "incyte" and "paml", you're actually referring to the address ranges:
  example:

acl 101 <incyte's address range>
acl 101 <paml's address range>

Then create 2 new acl's that have specific names for each (incyte and paml) and apply them to the appropriate crypto map statements.

Mark

Ok, I know you both have to be thinking "this guy is an idiot" but unfortunately I'm the one stuck doing this and if it wasn't for you guys helping me, I'd be in a real world of hurt.  So thank you so much and I hope you're not losing you patience with me.

That being said :)

If I were to create the no_nat acls, which part of the paml acl(s) would I change to say 'no_nat', since paml is the one occupying the 'nat 0'?

It doesn't specify just an ip range, it seems to have a particular ip (workstation?) that it's giving access to particular ranges and ip's.

access-list PAML_match permit ip host 192.168.0.7 172.30.0.0 255.255.255.0
access-list PAML_match permit ip host 192.168.0.7 172.30.1.0 255.255.255.0
access-list PAML_match permit ip host 192.168.0.7 host 172.30.3.56
access-list PAML_match permit ip host 192.168.0.7 host 172.30.3.200
access-list PAML_match permit ip host 192.168.0.7 host 172.30.99.99

Mark

Perfect!  I'll give it a shot and let you know how it goes!

Again, I can't say thank you enough, to both you and periferral!

Thanks again.

Mark

periferral,
 Be careful with the 2nd site. Notice that the "inland_nat" list does NOT get applied to nat 0.. it is applied to a different nat process (2), so they would not be included in acl 101....

Only PAML and the new incyte networks go in the no_nat acl...

Thanks lrmoore. Good catch.

would I delete this line:

nat (inside) 3 access-list incyte_match 0 0

Thanks.

mark

yes

Ok, hopefully this is the last question.

How does it know what isakmp policy is going to what?

example, I created a new isakmp policy for my config on Site A for 3des encryption, because my other one was for des?  Or did I just answer my own question?

Mark

doesnt matter. It will try all isa policies till one is matched. isa policies is not per tunnel. its more a global policy

Well, I'll be re-visiting this issue soon, but for now, I've had to "undo" everything I've done.

I have a vpn client based setup and need that to work.  Somewhere in all of this it has stopped working.  I have "un-did" everything I've done and it still won't work.

The only thing now that is different from what it was is that I upgraded the license to enable 3des, but I didn't change anything in the client configuration, I left it as "des".  I'm going to post a new question in this TA for that now.

Thank you very much for all of your help though.  I believe if I would have gotten to test it, that it would have worked.  But now I know how to do it when I re-set it up.  Thanks again.

Mark