cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
320
Views
0
Helpful
5
Replies

VPN Termination end point "through" ASA

RyanJohnstone
Level 1
Level 1

Can someone provide any guidance on whether below is possible please....

We have an ASA with two interfaces, these interfaces are configured as below (IP addresses changed)

e0/0 - 10.1.1.1 / 24

e0/1 - 20.1.1.1 / 24

We want to build an L2TP/IPSec VPN tunnel to terminate on the e0/1 (20.1.1.1) interface but we want it to come into the ASA via the  e0/0 (10.1.1.1) interface.  So in effect we would ingress via e0/0 and transit "through" the ASA and terminate on e0/1.

The error being thrown up for this is as follows

6Mar 26 201415:56:34110002172.31.216.11500  Failed to locate egress interface for UDP from inside:172.31.216.11/500 to 20.1.1.1/500

 

In the above log entry, 172.31.216.11 is the L2TP/IPSec client and has entered the ASA via the inside (e0/0 - 10.1.1.1) interface

Can anyone provide any guidance on if this is achievable.

Thanks

Ryan

 

 

5 Replies 5

Marvin Rhoads
Hall of Fame
Hall of Fame

No you canot do that as far as I know.

You could enable IPsec on the e0/0 interface (in addition to e0/1) and use that as an alternative end point - although it's hard to envision a scenario in which it would be a rational choice to terminate a VPN on both the inside and outside interface or an ASA.

Beyond the mechanics of the configuration, what are you trying to achieve functionally?

Thanks for the reply Marvin.  I have responded to an earlier post with some more details so will try not to repeat myself.  The key functionallity i require is that devices need to have a single VPN connection entry so one FQDN/IP address.  From the internet they hit the VPN fine on the global address, however we have an "untrusted" wireless environment where we issue clients with only public DNS servers to use (having an internal DNS is not an option), from this untrusted wireless environment though we want to have the VPN concentrator accessible via its inside interface but using the public ip address of its outside interface, hence we would not pass out to the internet and back in.

I have worked around this by inserting an ASA between the clients and VPN ASA which is fine except i would if possibe like to avoid dedicating another ASA for this purpose.

The main question here though is whether we could "pass through" this ASA to do this and you have clarifed this is very likely not possible so thats of great help

Thanks again

Ryan

 

 

 

 

No, it's not intended to be configured that way (I remember there were some very dirty tricks to make it work with some NAT-rules; was here on the forum some time ago). But what's the reason that you want to do that? If it's a known VPN-FQDN that should work from outside and also from inside, then you have to provide your internal users with a different DNS-reply (the internal IP) for that FQDN and provide your external users with the real outside IP of the ASA.

Thanks for the reply Karsten.  The issue i am trying to work around is the lack of an internal DNS, client devices only have access to an external public DNS so are pulling the IP from here when supplying the FQDN.  I am trying to avoid having to build an internal DNS as this is the only purpose it would serve.  I cant push these client devices to the official internal corporate DNS due to some security constraints we have to work with, as such i would need to build a local internal DNS and DMZ it off and direct clients to this....

At present i have worked around by inserting an intermediate ASA which has an outside interface in the same layer 2 network as the ASA with the global IP i am termintaing the VPN connections on.  This works fine and i have no real issues with this config bar the need to tie up another ASA to do it!

Thanks for clarifying there is no official way to pass through the ASA, i suspected this was the case but wanted to check to confirm my suspicions.  Certainly not going to look at any form of unsupported config tricks to try and get it working which may cause otehr issues down the line, if its not intended to work this way then we will not be pursuing it.

Ryan

You say that having an internal DNS is not an option, but in my opinion, the extra ASA adds much more complexity then an additional DNS would.

So just some examples for setting up a DNS:

  1. Use an old IOS-router as a DNS-server. The IOS includes a nearly full featured DNS-server that could sit with one interface in the guest-net and forward DNS-queries to the internet. For the VPN-FQDN the router would answer with the local ASA-address
  2. Use a simpe PC like a Rasberry Pi with a resolver-software like unbound. If I remember right it was also possible to serve locally configured replies.