Connecting the world…

translation

ISA 2006 Link Translation

Web pages returned from a Web server published by a Microsoft® Internet Security and Acceleration (ISA) Server 2006 Web publishing rule may include links containing internal names of computers or Web sites and internal paths to Web content. Because external clients cannot resolve these internal names, these links will be broken unless the internal names are replaced by the public names of published Web sites. ISA Server includes a built-in Web filter named Link Translation Filter, which uses mappings to translate internal names in links on Web pages to publicly resolvable names. Each mapping translates an internal URL (or part of a URL) to a public equivalent. For example, a mapping can translate the internal URL http://team to the public URL https://www.team.contoso.com. Link translation mappings are stored in tables called link translation dictionaries.

Today I had a problem where the remote user wanted to request the following URL https://www.booches.nl/configuration/service.jsp. This URL isn’t allowed and needed to be redirected. ISA’s Link Translation was the solution for me. I configured the following Link Translation.

isa-lt

The following Link Translation rule translates the URL above in https://www.booches.nl/configuration/denied.html.

It works for me!!!

Policy NAT on Cisco router

A colleague of mine had to implement an IPSec VPN tunnel from a customer to a supplier. The customer has a Cisco router for connecting to the Internet, so nothing special. The router is already setup and in production. Configuring an extra IPSec VPN tunnel isn’t very hard, the most important part is the negotiation of Phase 1 and Phase 2 credentials for the IPSec VPN connection.

This particular situation was different, because the customer has to NAT his local IP addresses into the VPN tunnel. I don’t actual configure this quiet often on routers, but more on firewalls. I setup a testing environment with GNS3 to do my own configuration.

The testing environment is displayed below. When connecting from the LAN from R1 (10.1.1.0/24) to the Internet normal NAT overload in configured. In the picture the network behind R3 represents the Internet. When connecting from R1 to R2, the source IP address (Inside Local) is translated to an address from the pool 10.22.44.0/24 (Inside Global). There is also a static NAT mapping for IP address 10.1.1.222 into the VPN tunnel (10.22.44.222).

POLNAT-RTR

At first I configured the environment like showed above. I configured the different interfaces and the corresponding IP addresses. Router R1 and R2 use router R3 as default gateway. The configuration of the specific routers is attached at the end of the post.

The first snippet shows the necessary NAT configuration on R1 for the Internet connection.

interface Loopback0
description INSIDE
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
interface FastEthernet0/0

description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto

!
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 212.123.212.11
!
ip access-list extended ACL-NAT
permit ip 10.1.1.0 0.0.0.255 any

When trying to ping Lo0 on router R3, I see the following NAT table on router R1.

R1#ping 192.168.3.1 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/46/76 ms
R1#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:3   10.1.1.1:3         192.168.3.1:3      192.168.3.1:3

This proves that regular NAT overloading works perfectly with the current configuration. Next I configured the Policy IPSec VPN between routers R1 and R2. The configuration isn’t that spectacular, you should pay attention to the NAT statements and ACL statements. I even configured reverse route injection for the LAN network of R2. When enabling reverse route injection a route with the remote network (172.16.2.0) pops up in the routing table. This feature can be used when redistributing static routes into a routing protocol like EIGRP.

Next I will show some snippets, with some comments, of the configuration of router R1.

\\ Specifying the Phase I and Phase II properties for the IPSec VPN

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key VPN@Booches address 212.123.212.10
!
crypto ipsec transform-set VPN-TS esp-aes 256 esp-sha-hmac
!
crypto map CM-VPN-R2 10 ipsec-isakmp
set peer 212.123.212.10
set transform-set VPN-TS
match address VPN-R2
reverse-route

!

\\ Loopback interface with 2 IP addresses for testing purposes

\\ Secondary IP address is used for static policy NAT testing

interface Loopback0
ip address 10.1.1.222 255.255.255.0 secondary
ip address 10.1.1.1 255.255.255.0
ip nat inside

!

\\ Outside interface with the crypto map applied to this interface
interface FastEthernet0/0
description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto
crypto map CM-VPN-R2

!

ip nat translation timeout 30

\\ NAT pool for dynamic policy NATZ
ip nat pool LAN-R2 10.22.44.1 10.22.44.254 netmask 255.255.255.0

\\ Default NAT for regular Internet related traffic
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload

\\ NAT statement for dynamic policy NAT and static policy NAT
ip nat inside source list ACL-POLICY-NAT pool LAN-R2 overload
ip nat inside source static 10.1.1.222 10.22.44.222 route-map RM-STATIC-NAT extendable

!

\\ ACL to define traffic to be NATted for regular Internet related traffic

ip access-list extended ACL-NAT
deny   ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255
deny   ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 any

\\ ACL to define traffic to be dynamic policy NATted into IPSec VPN tunnel
ip access-list extended ACL-POLICY-NAT

deny   ip host 10.1.1.222 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255

\\ ACL to define traffic to be static policy NATted into IPSec VPN tunnel
ip access-list extended ACL-STATIC-POLICY-NAT
permit ip host 10.1.1.222 172.16.2.0 0.0.0.255

\\ ACL to define interesting traffic for the IPSec VPN tunnel
ip access-list extended VPN-R2
permit ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
!

\\ Route map static to configure static policy NAT statement
route-map RM-STATIC-NAT permit 10
match ip address ACL-STATIC-POLICY-NAT

I issued some ping commands and looked at the IP NAT Translations table to test the environment. The test results are displayed below.

SOURCE 10.1.1.1 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/120 ms
R1#ping 212.123.212.11 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/48/84 ms
R1#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:29  10.1.1.1:29        212.123.212.11:29  212.123.212.11:29
icmp 10.22.44.1:28     10.1.1.1:28        172.16.2.1:28      172.16.2.1:28

SOURCE 10.1.1.222 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/84 ms
R1#ping 192.168.3.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/60 ms
R1#sh ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:37  10.1.1.222:37      192.168.3.1:37     192.168.3.1:37
icmp 10.22.44.222:36   10.1.1.222:36      172.16.2.1:36      172.16.2.1:36

 

SOURCE 172.16.2.1 (R2) – DESTINATION 10.22.44.222 (R1)

R2#ping 10.22.44.222 source 172.16.2.1

Packet sent with a source address of 172.16.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/53/112 ms

All ICMP testing gave positive results and policy-based NAT on the Cisco router is working perfectly.

Configurations:

Failed to establish VPN through PIX

We migrated our Internet connection lately and reconfigured our PIX firewall. We added some memory to install the latest firmware version (8.0(4)). After putting the PIX firewall in production some of the employees were complaining they couldn’t establish any PPTP VPN Tunnels anymore to customers.

Every time when some one called me, I tried it myself and I was always able to connect using a PPTP VPN Tunnel, but every time I was working remote and not at the office. So I always thought that something was wrong with there laptops, but today I encountered the problem myself.

Looking at the logging of the PIX firewall, I saw the following error message:

%ASA-3-305006: regular translation creation failed for protocol 47 src inside:<IP address> dst outside:<IP address>

The error message indicates that there is no NAT mapping for the specified traffic, which could direct you in the wrong direction. I checked the NAT mappings to be sure, but as I already thought, this couldn’t be the cause of the problem.

PPTP uses a TCP connection that uses port 1723 and an extension of generic routing encapsulation (GRE) [protocol 47] to carry the actual data (PPP frame). The TCP connection is initiated by the client, followed by the GRE connection that is initiated by the server. Because the PPTP connection is initiated as TCP on one port and the response is GRE protocol, the PIX Adaptive Security Algorithm (ASA) does not know that the traffic flows are related.

The PPTP fixup feature in version 6.3 allows the PPTP traffic to traverse the PIX when configured for PAT. Stateful PPTP packet inspection is also performed in the process. The fixup protocol pptp command inspects PPTP packets and dynamically creates the GRE connections and translations necessary to permit PPTP traffic. Specifically, the firewall inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing call request and reply sequence is tracked. Connections and/or translations are dynamically allocated as necessary to permit subsequent secondary GRE data traffic. The PPTP fixup feature must be enabled for PPTP traffic to be translated by PAT.

So I had to configure the fixup protocol pptp feature with the following command:

fw01(config)# fixup protocol pptp 1723

As stated before, we are using fireware version 8.0(4). This version doesn’t support the fixup protocol pptp command and the converts the command an inspect pptp command as shown below.

fw01(config)# fixup protocol pptp 1723
INFO: converting ‘fixup protocol pptp 1723’ to MPF commands

!

!

policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect pptp