cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1252
Views
0
Helpful
2
Replies

PIX version 6.3 default route through IPsec tunnel

1stsourceparts
Level 1
Level 1

We have a PIX 501 running IOS version 6.3.1.

There are currently 3 IPsec tunnels active as detailed below.

What we would like is to have all default traffic (0.0.0.0 0.0.0.0) routing out through the CenterLine tunnel so that the traffic can be firewalled at the other end of the tunnel.  Given the connecting firewall is a Sonicwall what would needed to be changed in the configuration on the PIX to accomplish this?

thank you

PIX Version 6.3(1)

interface ethernet0 10baset

interface ethernet1 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password 86AZXXmRLxfv/oUQ encrypted

passwd 86AZXXmRLxfv/oUQ encrypted

hostname Site A

domain-name default.int

clock timezone MST -7

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 ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol tftp 69

names

name 75.75.75.2 CovadHub

name 75.48.25.12 Sonicwall

access-list 101 permit ip 10.10.5.0 255.255.255.0 10.10.1.0 255.255.255.0

access-list 101 permit ip 10.10.5.0 255.255.255.0 10.10.2.0 255.255.255.0

access-list 101 permit ip 10.10.5.0 255.255.255.0 10.10.3.0 255.255.255.0

access-list 101 permit icmp any any echo-reply

access-list 101 permit icmp any any echo

access-list 102 permit ip 10.10.5.0  255.255.255.0 10.10.2.0 255.255.255.0

access-list 103 permit ip 10.10.5.0 255.255.255.0 10.10.1.0 255.255.255.0

access-list 104 permit ip 10.10.5.0 255.255.255.0 10.10.3.0 255.255.255.0

pager lines 24

logging on

logging monitor debugging

logging buffered warnings

icmp permit 10.10.5.0 255.255.255.0 inside

mtu outside 1500

mtu inside 1500

ip address outside 75.25.14.2 255.255.255.0

ip address inside 10.10.5.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm location 10.10.5.0 255.255.255.0 inside

pdm logging informational 100

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

conduit permit icmp any any

route outside 0.0.0.0 0.0.0.0 75.25.14.1 1

timeout xlate 0:05: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

ntp server 132.163.4.102 source outside

ntp server 129.7.1.66 source outside

http server enable

http 10.10.1.0 255.255.255.0 inside

http 10.10.5.0 255.255.255.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 pix11 esp-des esp-md5-hmac

crypto map peer11 10 ipsec-isakmp

crypto map peer11 10 match address 102

crypto map peer11 10 set peer 75.95.21.41

crypto map peer11 10 set transform-set pix11

crypto map peer11 11 ipsec-isakmp

crypto map peer11 11 match address 103

crypto map peer11 11 set peer Sonicwall

crypto map peer11 11 set transform-set pix11

crypto map peer11 12 ipsec-isakmp

crypto map peer11 12 match address 104

crypto map peer11 12 set peer 75.62.58.28

crypto map peer11 12 set transform-set pix11

crypto map peer11 interface outside

isakmp enable outside

isakmp key ******** address 75.62.58.28 netmask 255.255.255.240

isakmp key ******** address Sonicwall netmask 255.255.255.224

isakmp key ******** address 75.95.21.41 netmask 255.255.255.252

isakmp identity address

isakmp keepalive 10

isakmp nat-traversal 20

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

isakmp policy 11 authentication pre-share

isakmp policy 11 encryption des

isakmp policy 11 hash md5

isakmp policy 11 group 2

isakmp policy 11 lifetime 28800

isakmp policy 12 authentication pre-share

isakmp policy 12 encryption des

isakmp policy 12 hash md5

isakmp policy 12 group 2

isakmp policy 12 lifetime 36000

telnet 10.10.5.0 255.255.255.0 inside

telnet 0.0.0.0 0.0.0.0 inside

telnet timeout 5

ssh 0.0.0.0 0.0.0.0 outside

ssh 0.0.0.0 0.0.0.0 inside

ssh timeout 60

console timeout 0

dhcpd address 10.10.5.70-10.10.5.101 inside

dhcpd dns 10.10.1.214

dhcpd lease 43200

dhcpd ping_timeout 750

dhcpd domain default.int

dhcpd auto_config outside

dhcpd enable inside

terminal width 80

Cryptochecksum:36d2c26afa8

03957d3659

868d9219f8

2

: end

1 Accepted Solution

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

You dont really configure any type of default route for the L2L VPN. You rather match traffic with "any" destination on the L2L VPN configuration. Basicly you would be configuring the L2L VPN crypto map ACL with the destination "any"

I guess in your case that would be the ACL named "103".

access-list 103 permit ip 10.10.5.0 255.255.255.0 any

no access-list 103 permit ip 10.10.5.0 255.255.255.0 10.10.1.0 255.255.255.0

Naturally your NAT0 ACL configuration should also reflect this change. I suppose the remote end Sonicwall would  be doing the private to public NAT while accessing Internet in this case. I guess in this case the NAT0 ACL might even be just this one ACL rule

access-list 101 permit ip 10.10.5.0 255.255.255.0 any

BUT What I am wondering though at the moment mainly is the fact that it holds a priority "11" in the "crypto map" that has it in between the 2 other L2L VPN connections.

crypto map peer11 10 ipsec-isakmp

crypto map peer11 10 match address 102

crypto map peer11 10 set peer 75.95.21.41

crypto map peer11 10 set transform-set pix11

crypto map peer11 11 ipsec-isakmp

crypto map peer11 11 match address 103

crypto map peer11 11 set peer Sonicwall

crypto map peer11 11 set transform-set pix11

crypto map peer11 12 ipsec-isakmp

crypto map peer11 12 match address 104

crypto map peer11 12 set peer 75.62.58.28

crypto map peer11 12 set transform-set pix11

If you changed the destination address of "103" L2L VPN crypto ACL to "any" I would imagine that it would probably cause so that the last L2L VPN connection with priority "12" might stop working since the the previous connection already matches to "any" destination address from your "inside" network.

The solution might be to remove the current priority "11" configuration and add it with "13" for example so that the other 2 L2L VPN connections would keep working and all the rest of the traffic would be forwarded to the L2L VPN connection with the Sonicwall as the remote peer.

no crypto map peer11 11 ipsec-isakmp

no crypto map peer11 11 match address 103

no crypto map peer11 11 set peer Sonicwall

no crypto map peer11 11 set transform-set pix11

crypto map peer11 13 ipsec-isakmp

crypto map peer11 13 match address 103

crypto map peer11 13 set peer Sonicwall

crypto map peer11 13 set transform-set pix11

I will have to say that this is how I expect it should work. I have worked with L2L VPN which have been configured this way but its pretty rare.

If you are going to try something like this, naturally be ready to revert back to the old configuration with your remote peer admins if things dont work. I imagine the hardest configurations changes need to be done on the remote end while your ends configuration should be pretty simple.

Hope this helps

- Jouni

View solution in original post

2 Replies 2

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

You dont really configure any type of default route for the L2L VPN. You rather match traffic with "any" destination on the L2L VPN configuration. Basicly you would be configuring the L2L VPN crypto map ACL with the destination "any"

I guess in your case that would be the ACL named "103".

access-list 103 permit ip 10.10.5.0 255.255.255.0 any

no access-list 103 permit ip 10.10.5.0 255.255.255.0 10.10.1.0 255.255.255.0

Naturally your NAT0 ACL configuration should also reflect this change. I suppose the remote end Sonicwall would  be doing the private to public NAT while accessing Internet in this case. I guess in this case the NAT0 ACL might even be just this one ACL rule

access-list 101 permit ip 10.10.5.0 255.255.255.0 any

BUT What I am wondering though at the moment mainly is the fact that it holds a priority "11" in the "crypto map" that has it in between the 2 other L2L VPN connections.

crypto map peer11 10 ipsec-isakmp

crypto map peer11 10 match address 102

crypto map peer11 10 set peer 75.95.21.41

crypto map peer11 10 set transform-set pix11

crypto map peer11 11 ipsec-isakmp

crypto map peer11 11 match address 103

crypto map peer11 11 set peer Sonicwall

crypto map peer11 11 set transform-set pix11

crypto map peer11 12 ipsec-isakmp

crypto map peer11 12 match address 104

crypto map peer11 12 set peer 75.62.58.28

crypto map peer11 12 set transform-set pix11

If you changed the destination address of "103" L2L VPN crypto ACL to "any" I would imagine that it would probably cause so that the last L2L VPN connection with priority "12" might stop working since the the previous connection already matches to "any" destination address from your "inside" network.

The solution might be to remove the current priority "11" configuration and add it with "13" for example so that the other 2 L2L VPN connections would keep working and all the rest of the traffic would be forwarded to the L2L VPN connection with the Sonicwall as the remote peer.

no crypto map peer11 11 ipsec-isakmp

no crypto map peer11 11 match address 103

no crypto map peer11 11 set peer Sonicwall

no crypto map peer11 11 set transform-set pix11

crypto map peer11 13 ipsec-isakmp

crypto map peer11 13 match address 103

crypto map peer11 13 set peer Sonicwall

crypto map peer11 13 set transform-set pix11

I will have to say that this is how I expect it should work. I have worked with L2L VPN which have been configured this way but its pretty rare.

If you are going to try something like this, naturally be ready to revert back to the old configuration with your remote peer admins if things dont work. I imagine the hardest configurations changes need to be done on the remote end while your ends configuration should be pretty simple.

Hope this helps

- Jouni

That did the job!

thank you