cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
663
Views
8
Helpful
9
Replies

Routing problem, PIX to PIX VPN, to MPLS cloud

itfwsteel
Level 1
Level 1

Hi,

I have an issue with routing while trying to setup a new pix at a remote location. The PIX at site B connects to our PIX at our headquaters, site A. Once it connects it needs to hop to an internal router which then sends it across an MPLS cloud to a datacenter housing our oracle erp app. I can't seem to find out where the traffic is getting lost. As an interim solution the users at site B are using the vpn client software to connnect to the firewall at site A and in that case it works fine. Defeats the whole site to site vpn though. Any ideas anybody? Thanks

I can provide a simple line topo if needed with ip's.

1 Accepted Solution

Accepted Solutions

Hi,

You have a ACL "client_vpn" bounded to "Nat(inside) 0" in the main site. You need to include the access from 144.140.128.0/17 and 142.85.0.0/16 networks to the 10.110.0.0/16 networks in that ACL as follows.

Kindly modify the ACL as follows, to allow the same.

access-list client_vpn permit ip 142.85.0.0 255.255.0.0 10.110.0.0 255.255.0.0

access-list client_vpn permit ip 144.140.128.0 255.255.128.0 10.110.0.0 255.255.0.0

access-list client_vpn permit ip 10.0.0.0 255.0.0.0 192.168.254.0 255.255.255.0

access-list client_vpn permit ip 10.0.0.0 255.0.0.0 10.110.0.0 255.255.0.0

access-list client_vpn deny ip any any

Hope this helps.

-VJ

View solution in original post

9 Replies 9

vijayasankar
Level 4
Level 4

Hi,

Kindly provide the configuration of PIX at Site B and A(excluding any sensitive details like public ip address,etc.).

Also provide the topology with ips of involved components.

-VJ

dbnorton
Level 1
Level 1

Have you thought about setting up a GRE tunnel between a router at site A and site B? We are currently running IPSEC tunnels between all our remote offices on PIX firewalls and then we are using routers on the back end and make GRE tunnels to our core environment. We currently are running EIGRP across the GRE tunnels and it work great. Just an idea.

itfwsteel
Level 1
Level 1

Here the meat of the configs. Let me know if you need other info. I do have the "show cry is sa" and "show cry ip sa" available too.

Thanks for the help.

______Main

access-list client_vpn permit ip 10.0.0.0 255.0.0.0 192.168.254.0 255.255.255.0

access-list client_vpn permit ip 10.0.0.0 255.0.0.0 10.110.0.0 255.255.0.0

access-list client_vpn deny ip any any

access-list Split_TunnelAcl permit ip 10.0.0.0 255.0.0.0 any

access-list Split_TunnelAcl permit ip 142.85.0.0 255.255.0.0 any

access-list Split_TunnelAcl permit ip 144.140.128.0 255.255.128.0 any

access-list VPN_to_Site1 permit ip 10.0.0.0 255.0.0.0 10.110.0.0 255.255.0.0

access-list VPN_to_Site1 deny ip any any

ip local pool vpn_pool 192.168.254.10-192.168.254.200

nat (inside) 0 access-list client_vpn

sysopt connection permit-ipsec

crypto ipsec transform-set my_encry_set esp-3des esp-md5-hmac

crypto dynamic-map dynmap 30 set transform-set my_encry_set

crypto map outside_map 10 ipsec-isakmp

crypto map outside_map 10 match address VPN_to_Site1

crypto map outside_map 10 set peer 65.X.X.180

crypto map outside_map 10 set transform-set my_encry_set

crypto map outside_map 20 ipsec-isakmp dynamic dynmap

crypto map outside_map interface outside

isakmp enable outside

isakmp key ******** address 65.X.X.180 netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

______Site1

access-list VPN_to_Main permit ip 10.110.0.0 255.255.0.0 10.0.0.0 255.0.0.0

ip address inside 10.110.1.1 255.255.255.0

nat (inside) 0 access-list VPN_to_Main

sysopt connection permit-ipsec

crypto ipsec transform-set my_encry_set esp-3des esp-md5-hmac

crypto map outside_map 10 ipsec-isakmp

crypto map outside_map 10 match address VPN_to_Main

crypto map outside_map 10 set peer 12.X.X.X

crypto map outside_map 10 set transform-set my_encry_set

crypto map outside_map interface outside

isakmp enable outside

isakmp key ******** address 12.X.X.X netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

Once connected to the Main Site Firewall the next hop is 10.10.30.2 going to a final destination of 142.85.0.0 and 144.140.128.0 as per these routes

route inside 10.110.0.0 255.255.0.0 10.10.30.2 1 (not currenlty on the firewall but suspect it may need to be in some form. When I put it in all traffic from Site1 one to Main stops working)

route inside 142.85.0.0 255.255.0.0 10.10.30.2

route inside 144.140.128.0 255.255.128.0 10.10.30.2

Hi,

On Site 1, you need to modify the ACL VPN_to_Main as follows. Should include the remote networks also in the ACL

used for crypto.

access-list VPN_to_Main permit ip 10.110.0.0 255.255.0.0 10.0.0.0 255.0.0.0

access-list VPN_to_Main permit ip 10.110.0.0 255.255.0.0 142.85.0.0 255.255.0.0

access-list VPN_to_Main permit ip 10.110.0.0 255.255.0.0 144.140.128.0 255.255.128.0

On Main site, you need to modify the ACL,VPN_to_Site1 as follows, Should include the remote networks also in the ACL used for crypto.

access-list VPN_to_Site1 permit ip 10.0.0.0 255.0.0.0 10.110.0.0 255.255.0.0

access-list VPN_to_Site1 permit ip 142.85.0.0 255.255.0.0 10.110.0.0 255.255.0.0

access-list VPN_to_Site1 permit ip 144.140.128.0 255.255.128.0 10.110.0.0 255.255.0.0

Also you should only have the following routes in the main site firewall.

route inside 142.85.0.0 255.255.0.0 10.10.30.2

route inside 144.140.128.0 255.255.128.0 10.10.30.2

This will resolve your issue.

Note: I could see that 10.0.0.0 255.0.0.0 network is the inside network at Main site. Is it correct?

I could also see that the site1 is having 10.110.1.0 255.255.255.0 as its inside network??? which actually falls in the supernet 10.0.0.0/8 used at Main site. Why this is implemented in this way?

Also the crypto acls are referring to 10.110.0.0 255.255.0.0 inspite of having a 10.110.1.0/24 network.

Im not sure why it is done so.

You may have to Correct the ACLs/subnets suitably, if required.

Hope this helps. Kindly rate the post if it was helpful

-VJ

Thanks VJ, helpful so far. Unfortunately no luck. I made sure the acls were correct, and now from site 1 I do see some hits on the acl to the 144 network. But I see nothing on the main pix's acls headed back the other way. Seems like the traffic is getting lost after it gets to the main site. I see nothing in the log files, presumably because it's through the tunnel. Any other ideas?

On the router which is the next hop 10.10.30.2 there is a route pointing 10.110 traffic back to the firewall. don't know if this is even necessary.

Thanks for the help again.

Was able to track this down in the log files. And forgot to mention, I am accepting both VPN clients and site to site VPN's to the external interface. I suspect this might be causing a conflict in my config somehow.

305005: No translation group found for tcp src outside:10.110.XX.XXX/3028 dst inside:144.140.XXX.205/80

I thought with the nat (inside) 0 command no translation would be made?

Hi,

You have a ACL "client_vpn" bounded to "Nat(inside) 0" in the main site. You need to include the access from 144.140.128.0/17 and 142.85.0.0/16 networks to the 10.110.0.0/16 networks in that ACL as follows.

Kindly modify the ACL as follows, to allow the same.

access-list client_vpn permit ip 142.85.0.0 255.255.0.0 10.110.0.0 255.255.0.0

access-list client_vpn permit ip 144.140.128.0 255.255.128.0 10.110.0.0 255.255.0.0

access-list client_vpn permit ip 10.0.0.0 255.0.0.0 192.168.254.0 255.255.255.0

access-list client_vpn permit ip 10.0.0.0 255.0.0.0 10.110.0.0 255.255.0.0

access-list client_vpn deny ip any any

Hope this helps.

-VJ

VJ,

That was it, all is working properly now. Thanks A LOT for your help. I've been beating my head on this one for way too long. I'll be sure to rate it.

regards,

b

Hi Brian,

Glad to know that the issue is resolved.

Thanks for updating us.

-VJ

Review Cisco Networking for a $25 gift card