Solved

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

Posted on 2006-06-12
7
987 Views
Last Modified: 2013-11-16
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#
**************************************************************************************
0
Comment
Question by:netman70
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
7 Comments
 
LVL 9

Expert Comment

by:stressedout2004
ID: 16891436
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?
0
 

Author Comment

by:netman70
ID: 16892776
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
0
 
LVL 9

Expert Comment

by:stressedout2004
ID: 16893913
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
0
Raise the IQ of Your IT Alerts

From IT major incidents to manufacturing line slowdowns, every business process generates insights that need to reach the people required to take action. You need a platform that integrates with your business tools to create fully enabled DevOps toolchains.

You need xMatters.

 

Author Comment

by:netman70
ID: 16897018
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.
0
 
LVL 9

Accepted Solution

by:
stressedout2004 earned 500 total points
ID: 16897896

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?

>>>> No, not unless you remove them. But the thing is we **need** to remove all of your static mapping and NAT 0. Noticed the first two commands I gave you:

clear configure nat
clear configure static

These commands will remove *all* your NAT and static statements. The reason we need to remove those statement is because of the order of precedence. NAT 0 is implemented first, then static, followed by policy NAT and lastly regular NAT and PAT. Because of the way you have your NAT/Static configured, we will never get the policy NAT to work which is the only solution to your dilemma.

If you look at your NAT and static, the IP doesn't change. For instance, when 192.168.0.2 goes outside, it still is 192.168.0.2, the real translation takes place on the Radware where 192.168.0.2 gets translated to a public IP.
There is really no *real* translation taking place on the PIX but a mere compliance of the working principles of the PIX
wherein all traffic traversing it must have either a NAT or Static rule.

This is where no nat-control comes in the picture. With no nat-control enable, the PIX will no longer require a NAT or a static  translation for traffic to be allowed through, however you still need the access-rule for outside to inside communication and ASA still applies. Just because you have no nat-control however doesn't mean you can't have NAT. You can combine both. So in your case NAT will be applied  for the 192.168.0.0 so they get translated to 10.97.212.68 but if and only if the traffic is destined to the your vendor's IPs.  If the traffic is destined to the internet then there will be no need for translation. Now as for the servers that needs to be accessible from the internet, by virtue of the no nat-control, you will no longer need a static mapping for it. Traffic from the internet will be allowed as long as there is an access-list configured allowing the traffic.


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

Yup, all access-rules remains the same. It's just the NAT that needs to change.

P.s Please take note that since your vendor requested that traffic from your internal network appears to be coming from
a single IP, the flow of traffic will be one way. Meaning, you will be able to access your vendors network, but your vendor will not be able to access yours.

0
 

Author Comment

by:netman70
ID: 16901482
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.
0
 
LVL 9

Expert Comment

by:stressedout2004
ID: 16902226
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.





0

Featured Post

Transaction Monitoring Vs. Real User Monitoring

Synthetic Transaction Monitoring Vs. Real User Monitoring: When To Use Each Approach? In this article, we will discuss two major monitoring approaches: Synthetic Transaction and Real User Monitoring.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The DROP (Spamhaus Don't Route Or Peer List) is a small list of IP address ranges that have been stolen or hijacked from their rightful owners. The DROP list is not a DNS based list.  It is designed to be downloaded as a file, with primary intention…
On Feb. 28, Amazon’s Simple Storage Service (S3) went down after an employee issued the wrong command during a debugging exercise. Among those affected were big names like Netflix, Spotify and Expedia.
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

696 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question