Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 231
  • Last Modified:

Network routing VPN etc.

Have a customer in DK who have been sold to a company in FI. In Findland they want to offer some Intranet sites to the users in DK.

We then made a site-to-site VPN between the DK subnet and the subnet in FI and then some DNS so the users in DK can browse intranet sites in FI. That works.

But now the guys in FI wants the DK users to browse another site on an IP address of 194.x.x.x and they want me to make it work through the VPN. But how should that be possible? As far as I know a 194.x.x.x address is a public address and the firewall in DK will route it to the Internet and not through the VPN.

What can I do? Which information do I have to ask the guys in Finland?
  • 2
1 Solution
It sounds like the folks in Finland are using public space that is not theirs -- a not too uncommon practice, though a bad idea.

You can do this.  You need to do at least one, maybe two, or even three, things: 1) add the 194.x.x.x destination to your ACL that specifies interesting traffic; and 2) depending on how you are tunneling the traffic and what type of device you are using to create the VPN, you may need to add a route 194.x.x.x to point the traffic down the tunnel, 3) exempt the 194.x.x.x traffic from the NAT policy.

If you are just doing traditional ESP tunnel mode on a Cisco IOS or PIX/ASA platform, you only need to do the 1st and 3rd.


TANGLADAuthor Commented:
Im using a Cisco Pix 501 with PDM interface only. Since I dont have the knowledge to use command line interface and telnet and things like that. But Im not that stupid at all, so if someone tells me how to configure this thing in command line way I can propably do it. The main thing in this scenario is that I think they are asking me to do something that is wrong or even impossible.
I personally have no experience with the PDM, though it has become a very popular way of managing the device.  That said, if you have already gone into the PDM to create the tunnel and just need to add another entry, you can just go into the PDM, and make sure that you add the entry.  Just add it the same as you did the entry.  You need to accomplish two things: 1) add to interesting traffic, and 2) exempt from NAT policy  

I think there would probably be a check box exempting the traffic from the NAT policy.

Alternatively, you could go into the CLI and look for the access-lists that specify NAT exemption and interesting traffic.  when you log in with the telnet password, you will get a ">" prompt.  Type "enable" and then type in the enable password to get the "#" prompt, which indicates you are in privileged mode and can modify the config.

The interesting traffic ACL will be reference by a line that looks like this:

crypto map <MAP_NAME> <SEQ_NUMBER>  match address <ACL>

most likely it will be something very similar to:

crypto map outside_map 10 match address outside_cryptomap_10

if you only have 1 site-to-site VPN, this is it, if you have multiple, then you will have multiple seqence numbers (10, 20,30, etc.), amd you need to check to make sure you have the right one.  Do this by looking for the "crypto map . . . set peer x.x.x.x" that matches the FI firewall address.

Once you have identified the correct ACL (the name of which is at the end of the "crypto map . . .  match address" statement), go look at the ACL (above in the config).

It should look something like this:

access-list outside_cryptomap_10 permit ip

all you need to do now is add a command that duplicates this entry, except for the destination address.  So (after typing "config t" to go into config mode):

access-list outside_cryptomap_10 permit ip 194.x.x.x
(assuming a Class C mask on the remote side) -- just make sure you replace "outside_cryptomap_10" with whatever the actual name of your access-list is.

then you need to look in the config for the "nat 0 (inside) access-list" statement.  it will probably be:

nat (inside) 0 access-list inside_outbound_nat0_acl

in any event this statement is referencing an access-list that exempts traffic from the NAT policy.  the name of the access-list in the above statement is "inside_outbound_nat0_acl."  Now look for that in the config.  You should see something like:

access-list inside_outbound_nat0_acl permit ip

so just type in (again replacing the "inside_outbound_nat0_acl" with your ACL's name if different):

access-list inside_outbound_nat0_acl permit ip 194.x.x.x

And you are done.  A couple of things to note:
1) the fact that you are accessing a non-RFC-1918 (i.e., not-private) remote ip block makes no difference. It just means that users on your network will not be able to access any sites that reside on the legitimate owner of the 194.x.x.x network.
2) you do not need a route for the 194.x.x.x network, because in the absence of a specific route, the PIX will just follow the default route for any 194.x.x.x destinations.  That is, it will see that it is not local and therefore forward it to its default gateway, which is probably your Internet router.  But the traffic will match both the interesting traffic ACL and the NAT exemption ACL and will therefore be encrypted and not be NATted before it gets forwarded to the Internet router.  Note that this is the same behavior currently being performed on all traffic: again you have you specific route to the network, so it get forwarded out to the default gateway *after* being encrypted and not NATted because it matched the two ACLs.
3) You *must* -- and I cant emphasize this enough -- not add these two access-list entries until the folks on the Finland side do the same.  And you *must* -- again this is critical -- add the exact opposite of what they add.  Meaning if Finland adds entries specifying source as, destination as, then you must add entries specifying source as, destination as  You cannot make your entry more or less specific.  It *must* be an exact mirror image of their entry otherwise the VPN will not work properly.  And if you add your entries without them doing theirs at the same time, it will likely break the existing VPN (to the network) until they add their side.  The NAT ACL is not as critical here, but the interesting traffic ACL is essential.  The most common cause of VPN connectivity problems is that the interesting traffic ACLs on each side do not exactly mirror each other line by line.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now