Link to home
Start Free TrialLog in
Avatar of netman70
netman70

asked on

PIX IOS 7.X Site-to-Site VPN question

Hi,

I have configured site-to-site VPN tunnels on a PIX but our vendor has made the following requirement to establish a VPN tunnel - they expect all traffic from my end to come from the following IP only -10.97.212.68 (not a part of our network). Can somebody help me with the syntax required for this configuration, please.

IP for Traffic from mycompany
10.97.212.68/32

IP for Traffic to myvendor
10.96.175.201/32
10.96.175.202/32
10.40.20.201/32
10.40.16.87/32
10.40.24.15/32
10.40.24.16/32
10.40.16.156/32

Key: abckey
\
**************************************************************************************
PIX Version 7.2(1)
!
hostname mycompany-PIX515E
domain-name mycompany.local
names
dns-guard
!
interface Ethernet0
 nameif outside
 security-level 0
 ip address 192.168.2.2 255.255.255.0
!
interface Ethernet1
 nameif inside
 security-level 100
 ip address 192.168.0.254 255.255.255.0
!
interface Ethernet2
 nameif dmz
 security-level 50
 ip address 192.168.1.1 255.255.255.0
!
boot system flash:/image
ftp mode passive
clock timezone CST -6
clock summer-time CDT recurring
dns server-group DefaultDNS
 domain-name mycompany.local
access-list outside-in extended permit icmp any any
access-list outside-in extended permit tcp any host 192.168.0.2 eq www
access-list outside-in extended permit tcp any host 192.168.0.2 eq 3389
access-list outside-in extended permit tcp any host 192.168.0.2 eq https
access-list outside-in extended permit tcp 64.18.0.0 255.255.240.0 host 192.168.0.2 eq smtp
access-list outside-in extended permit tcp any host 192.168.0.10 eq www
access-list outside-in extended permit tcp any host 192.168.0.10 eq https
access-list outside-in extended permit tcp any host 192.168.1.2 eq www
access-list outside-in extended permit tcp any host 192.168.1.2 eq 8080
access-list outside-in extended permit tcp any host 192.168.1.2 eq https
access-list outside-in extended permit tcp any host 192.168.1.3 eq www
access-list outside-in extended permit tcp any host 192.168.1.3 eq 8080
access-list outside-in extended permit tcp any host 192.168.1.3 eq https
access-list outside-in extended permit tcp any host 192.168.1.4 eq www
access-list outside-in extended permit tcp any host 192.168.1.4 eq 8080
access-list outside-in extended permit tcp any host 192.168.1.4 eq https
access-list dmz-in extended permit tcp host 192.168.1.2 any eq www
access-list dmz-in extended permit tcp host 192.168.1.2 any eq https
access-list dmz-in extended permit tcp host 192.168.1.2 eq www any
access-list dmz-in extended permit tcp host 192.168.1.2 eq https any
access-list dmz-in extended permit icmp 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0 echo-reply
access-list dmz-in extended permit udp host 192.168.1.2 any eq domain
access-list dmz-in extended permit tcp host 192.168.1.2 any eq 8080
access-list dmz-in extended permit tcp host 192.168.1.2 eq 8080 any
access-list dmz-in extended permit tcp host 192.168.1.2 any eq 1433
access-list dmz-in extended permit tcp host 192.168.1.2 eq 1433 any
access-list dmz-in extended permit icmp any any
access-list nonat extended permit ip 192.168.0.0 255.255.0.0 any
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu dmz 1500
asdm image flash:/asdm521.bin
asdm history enable
arp timeout 14400
nat-control
nat (inside) 0 access-list nonat
static (inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.255.0
static (inside,outside) 192.168.0.2 192.168.0.2 netmask 255.255.255.255
static (inside,outside) 192.168.0.10 192.168.0.10 netmask 255.255.255.255
static (dmz,outside) 192.168.1.2 192.168.1.2 netmask 255.255.255.255
static (dmz,outside) 192.168.1.3 192.168.1.3 netmask 255.255.255.255
static (dmz,outside) 192.168.1.4 192.168.1.4 netmask 255.255.255.255
access-group outside-in in interface outside
access-group dmz-in in interface dmz
route outside 0.0.0.0 0.0.0.0 192.168.2.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa authentication telnet console LOCAL
aaa authentication ssh console LOCAL
aaa authentication enable console LOCAL
no snmp-server location
no snmp-server contact
snmp-server community public
snmp-server enable traps snmp authentication linkup linkdown coldstart
no sysopt connection permit-vpn
telnet 192.168.0.0 255.255.255.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 5
ssh version 1
console timeout 0
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns migrated_dns_map_1
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns migrated_dns_map_1
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect http
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
!
service-policy global_policy global
prompt hostname context
: end
[OK]
mycompany-PIX515E#
**************************************************************************************
Avatar of stressedout2004
stressedout2004

A couple of questions:

1) Will the VPN terminate on the PIX above or to another PIX?
2) I noticed that the PIX above does not have a public IP, I am assuming that NAT for internet access is being done somewhere else, correct?
Avatar of netman70

ASKER

1) Will the VPN terminate on the PIX above or to another PIX?

VPN tunnel is between the PIX above and a CheckPoint VPN endpoint at the remote end,.

2) I noticed that the PIX above does not have a public IP, I am assuming that NAT for internet access is being done somewhere else, correct?

NAT for internet access is being done by a Radware LinkProof branch internet redundancy device.

Thank for your help
Here's the thing, in order for your network to appear to be coming from 10.97.212.68/32 when communicating to your vendor, you will need to implement policy NAT. In your case, you will have to switch the firewal NAT mode to no nat-control. Which means you have to reconfigure your entire NAT. The configuration below is what you need and they need to be enter in the order that they appear.

The following variables were used:

1) 1.1.1.1 is the Checkpoint public IP
2) abckey was used as a preshared key

Additional requirements:

- You need one is to one static NAT for the PIX external IP (192.168.2.2) on Radware.

If you have any questions on the configuration below let me know.

clear configure nat
clear configure static
no nat-control

access-list match_acl permit ip host 10.97.212.68 host 10.96.175.201
access-list match_acl permit ip host 10.97.212.68 host 10.96.175.202
access-list match_acl permit ip host 10.97.212.68 host 10.40.20.201
access-list match_acl permit ip host 10.97.212.68 host 10.40.16.87
access-list match_acl permit ip host 10.97.212.68 host 10.40.24.15
access-list match_acl permit ip host 10.97.212.68 host 10.40.24.16
access-list match_acl permit ip host 10.97.212.68 host 10.40.16.156

access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.96.175.201
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.96.175.202
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.20.201
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.16.87
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.24.15
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.24.16
access-list vpn_nat permit ip 192.168.0.0 255.255.255.0 host 10.40.16.156

global (outside) 1 10.97.212.68
nat (inside) 1 access-list vpn_nat

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

crypto map to_vendor 10 match address match_acl
crypto map to_vendor 10 set peer 1.1.1.1
crypto map to_vendor 10 set transform-set 3DES
crypto map to_vendor interface outside

isakmp identity address
isakmp enable outside

isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 lifetime 86400

tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key abckey
Thanks for your help stressedout2004.

1. When 'no nat-control' is enabled, does all my existing static mapping go away, along with the 'nat (inside) 0 access-list nonat' statement?

2. Do my existing access list remain the same? Will anything else change?

I have one-to-one NAT configured on the radware for all the servers and the PIX. I also have dynamic NAT setup for the (internal) 192.168.0.X subnet.

Thanks again.
ASKER CERTIFIED SOLUTION
Avatar of stressedout2004
stressedout2004

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks a million, stressedout2004. I giving you the points but if you could explain the difference between using 'no nat-control' and 'firewall transparent'.

Thanks for your help.
Firewall transparent is way way way different from no nat-control. The no nat-control dictates how PIX should process packet with "no matching translation" and still consults the routing table on where to send the packet to. The firewall transparent on the other hand, acts like a layer 2 firewall and allows you to add a firewall without any change on the IP structure however it can't be use as a default next hop for the internet and doesn't support NAT. When a PIX is in transparent mode, all it does pretty much is filter Layer 3 traffic. It doesn't do NAT, it doesn't do VPN for traffic that is meant to pass through it, it doesn't support dynamic routing etc... Of course it can do other stuff like DHCP server, pass ether type traffic etc.

e.g.

Supposing you have the following topology:

-------192.168.2.0/24 (internal LAN)-------(2.1)-Radware--(1.1.1.1)--------internet

If you introduced the PIX in routed mode, you would have the following:

--192.168.2.0/24 (internal LAN)-------(2.1)-PIX-(192.168.1.2)-----(1.1)-Radware--(1.1.1.1)--------internet

As you noticed you have to restructure the IP addressing and make way for another subnet between the PIX and the Radware. The default gateway of the internal LAN changes to the PIX instead of the Radware.

In Firewall Transparent mode, you would have:


--192.168.2.0/24 (internal LAN)--------PIX------(2.1)-Radware--(1.1.1.1)--------internet
                                                      (2.2)

The default gateway of the internal LAN will still be the Radware and not the PIX. And as you noticed PIX is assigned only one IP called the management IP that is *within* the internal network and you don't have to restructure the IP.
You still connect the inside interface to the internal LAN and the outside interface to the Radware but you don't give each interface an IP, only management IP. In this scenario, when PIX needs to route traffic, it doesn't lookup its routing table, rather it looks at its ARP table. ASA still applies, return traffic originated from the inside will be allowed without any access rules but traffic from the outside will need to be permitted.

Transparent mode won't help you in your case, you won't be able to terminate the VPN on the PIX.