topic Re: Interesting issue on the FWSM in Network Security

Interesting issue on the FWSM

gautamzone — Mon, 11 Mar 2019 16:42:41 GMT

Dear Friends,

I have an interesting issue on the FWSM.
There is a vpn concentrator connecting to the FWSM and the FWSM is its default gateway for outside world.

There is another third party network on the same network and its default gateway to outside world is the FWSM again.

Now, the nating on the third party network is done in its own network device and FWSM sees only public IP Addresses from this third party network.

But the vpn concentrator is public NAT'ed on the FWSM.

Now, the requirement is that the third party network needs to access the VPN COncentrator on its public IP for remote vpn.

Now, i am not sure if this possible.

Here is the relevant configuration for vpn concentrator, outside and third party network:

interface vlan102
nameif vpn
security-level 50
ip address 192.168.101.1 255.255.255.0 standby 192.168.101.2
no shut

interface vlanx
nameif outside
security-level 0
ip address 86.36.x.x x.x.x.x standby 86.36.x.x
no shut

interface vlan256
nameif thirdparty
security-level 50
ip address 86.36.x.x x.x.x.x standby 86.36.x.x
no shut

route thirdparty 86.36.50.x 255.255.255.224 86.36.x.x
route outside 0 0 86.36.x.x

Here is the flow of traffic:

1. Third Party network-->FWSM-->Public ip of COncentrator

Now i am not sure if traffic would go to outside interface? Because the public IP is a nAT'ed ip on the fwsm itself.
I dont know how the FWSM reacts if it sees a destination IP that is a NAT'ed IP for the real IP on another interface (vpn).
Please note that nat-control is enabled and i have also enabled same-security-traffic permit inter-interface.
There is no nating configured between the vpn and third party networks.

2. Return Traffic

This is clear. It should be VPN Concentrator-->FWSM-->Third party network gateway-->VPN client on third party network.

However now the confusion is the egress path. CUrrently, the problem is that the VPN concentrator is not reachable through the third party network but is reachable from outside world.

I suspect that this could be asymmetric routing issue.

Does anyone have a clue on what should be the approach here?

Thanks a lot
Gautam

Re: Interesting issue on the FWSM

Panos Kampanakis — Wed, 25 Nov 2009 23:48:38 GMT

From your description I got

3rd party-------(int1)FWSM(int2)--------concentrator

x y

x does not have a route to y

outside hosts have a route to y

y has a route to x

the 3rd party wants to talk to the concentrator y public ip address.

You can translate

static (int2,int1) y y

The the 3rd party will use the FWSM as its gateway and the FWSM will be able to send the traffic to the concentrators public ip.

The return traffic from the concentrator will hit the FWSM and the FWSM will send it to the 3rd party.

If I didn't grasp the problem correctly please explain what I am missing.

Re: Interesting issue on the FWSM

Kureli Sankar — Thu, 26 Nov 2009 03:14:17 GMT

Gautham,

I see the topology as below.

VPN_Concentrator-------

|--------(in)FWSM(out)-----Internet

3-RD-PARTY-N/W--------

You want the 3-rd party n/w to access the VPN using it pubic address. Is this correct?

It is so much easier to access the VPN using its inside address. Anyway you would have to do D-NAT on the FWSM to get this to work and of course you need same security permit intra-interface as well.

same-security-traffic permit intra-interface

static (in,in) VPN_outside-IP VPN_inside_IP -----> This is NAT for destination

static (in,in) 3_RD-PARTY-N/W_IP 3_RD-PARTY-N/W_IP -----> This is NAT for the source

See if this works.

Re: Interesting issue on the FWSM

Kureli Sankar — Thu, 26 Nov 2009 13:54:43 GMT

I missed to mention that you may have to add a host route on your VPN concentrator to send the traffic destined to the 3-rd party network via the FWSM. Otherwise it will cause assymetry meaning the

1. The request from the 3-rd party will come to the FWSM

2. The response from VPN will go directly to 3-rd party.

You also, would want to add translation for the VPN.

static (in,in) VPN_inside_IP VPN_inside_IP

Give this a shot and let us know how it goes.

Re: Interesting issue on the FWSM

gautamzone — Thu, 26 Nov 2009 16:12:50 GMT

Dear pkampana and kushankar,

Thanks a lot for your responses.

pkampana: When you mention y in the static (int2,int1) y y, are you saying the vpn concentrator's public ip as "y"?

Please note that the vpn concentrator is also nated on the FWSM in the following way:

static (vpn, outside) 86.36.x.x 192.168.101.11 netmask 255.255.255.255

So if i mention also:

static (vpn, thirdpartynetwork) 86.36.x.x 192.168.101.11 netmask 255.255.255.255

Is the second static statement possible? I am doubtful because my understanding is that you can nat to one ip only on one interface. You can't use the same nat'ed IP on the other interface. Please correct me if i am wrong.

kushankar: The vpn concentrator vlan terminates on the FWSM on one vlan interface and the third party network terminates on the FWSM on another vlan interface. I am sorry if i caused any confusion with my explanation. So, i guess that you recommended same-security-traffic permit intra-interface because you thought that both networks connect to the same vlan interface on the FWSM?

The reason we need the third party network to access the vpn concentrator on its public IP is because the vpn concentrator is external to the third party network. Moreover, they access the IPSEC VPN through the hostname which resolves to a public ip.

Thanks a lot

Gautam

Re: Interesting issue on the FWSM

Kureli Sankar — Fri, 27 Nov 2009 12:59:13 GMT

VPN_Concentrator-------(V)FWSM(O) ------Internet

(3)

3-RD-PARTY-N/W

Gautham,

Any time you post a question just put a clear text based diagram like this one. I paid more attention to what you said and missed the config part.

So I thought both VPN and 3-rd party are off the same interface. But, now I see they are not. But the solution is still the same.

You need to provide destination as well as source nat.

static (V,3) vpn_public_ip VPN_inside_IP

You may or may not need the following: (this depends on whether you have translation between these interfaces for these IPs or not)

Static (3,V) 3_rd_Party_IP 3_rd_Party_IP

static (v,3) vpn_inside vpn_inside

No need for same security intra.

Watch the logs and see what they say when you test the flow.

I hope this helps.

Re: Interesting issue on the FWSM

gautamzone — Fri, 27 Nov 2009 17:41:08 GMT

Dear Kushankar,

Thanks a lot. Will certainly try that one as soon as i get access to the device next which will be Dec 6 after the Eid holidays.

But i still did not get it where we have two static entries for the same IP address:

static (V,3) vpn_public_ip VPN_inside_IP

static (v,3) vpn_inside vpn_inside

I believe that only the first one is necessary?

v and V refer to the same interface

Thanks a lot

Gautam

Re: Interesting issue on the FWSM

Kureli Sankar — Sun, 29 Nov 2009 14:49:54 GMT

Gautham,

static (V,3) vpn_public_ip VPN_inside_IP ---> this is D-NAT. This tells the FWSM's 3-rd party interface to send all packets with the destination IP of

vpn_pulibc_ip to be sent to the VPN interface to the VPN_inside_IP.

Now, I do not know if you have provided translation for the source for VPN inside and 3-rd party address. I just provided identity translation for those as well. You may need it. Yes V and v mean the same VPN interface.

Good luck. Let us know how it goes. Logs are your best friend. Check the logs (debug level) when you test the connection.

-KS

Re: Interesting issue on the FWSM

gautamzone — Sun, 29 Nov 2009 15:04:28 GMT

Thanks KS. Will let you know how it goes

Re: Interesting issue on the FWSM

gautamzone — Sun, 13 Dec 2009 20:54:01 GMT

Thanks a lot KS. Your suggestion worked like a charm. !!

I did the static translation for vpn to third party and it worked great.

I never knew that a firewall could translate a real address to another address being the same on two different interfaces.

But it worked great. Thanks a lot again!!

Re: Interesting issue on the FWSM

Kureli Sankar — Sun, 13 Dec 2009 23:34:46 GMT

Very glad to hear Gautam.

-KS