topic Re: Configuring FWSM on 6509 in Network Security

Configuring FWSM on 6509

zulqurnain — Mon, 11 Mar 2019 18:54:32 GMT

Hi Everyone,

I have a scenario which I am working on; it is required from myself that on our 6509 FWSM I create 2 or 4 possible VLANs (maybe more) having different security levels; having different IP subnets; and machines connected to these VLANs should be mapped to FWSM outside interface so that inside users/LAN users connecting to these machines cannot know the real IP; meaning like we do the publishing of webserver using FW to internet, same way difference is I am not publishing to internet only to LAN users / users who will belong to inside of FWSM.

At present I have configure the 6509 and FWSM as below

6509-E
Created 4 VLANs with ofcourse different IPs and named with as below e.g.

VLAN 1 = 172.21.101.0/24 inside L2
VLAN 2 = 172.21.102.0/24 outside L3 (to make is routable on the LAN; servers will be published using this interface)
VLAN 3 = 172.21.103.0/24 SVRGRP_1
VLAN 4 = 172.21.104.0/24 SVRGRP_2

Assigned different ports on 6509 to different VLANs excluding VLAN 2 because it is to be used on FWSM as outside; configured the machines in those VLANs with corresponding IPs.

FWSM
As stated above VLAN 1 become inside and VLAN 2 outside; then created access-lists for all interfaces to allow any/any and configured icmp permit any for all interfaces;configured static for hosts in VLAN 3 and VLAN 4 and inside as following
static (SVRGRP_1,outside) 172.21.102.200 172.21.103.10 netmask 255.255.255.255
static (DVRGRP_2,outside) 172.21.102.201 172.21.104.12 netmask 255.255.255.255
static (inside,outside) 172.21.102.65 172.20.101.65 netmask 255.255.255.255

Machines in VLAN 3,4 and inside are able to ping to GW and LAN users without any problem & vice versa from LAN users to these hosts in different VLANs ( using their mapped IPs and not real IPs & this was one of the objectives); yet different VLANs e.g. VLAN 3 cannot ping to VLAN 4 on mapped IPs as well as real IPs;

Thus as said before only LAN client machines can ping VLAN 3 and VLAN 4 and inside hosts on their mapped IP.

I hope my objective is clear and one of the experts will help find a solution to my problem

Re: Configuring FWSM on 6509

Kureli Sankar — Fri, 15 Oct 2010 01:11:47 GMT

What are the security levels for these interfaces?

Have you enabled nat-control? (sh run all | i nat-control)

What do the logs say when ping fails between vlan 3 and vlan 4?

Have you configured translation between vlan 3 and vlan 4? Assuming vlan 3 is of higer security level than vlan 4 you need

static(SVRGRP_1,SVRGRP_2) 172.21.103.0 172.21.103.0 net 255.255.255.0

-KS

Re: Configuring FWSM on 6509

zulqurnain — Fri, 15 Oct 2010 10:52:24 GMT

Hi Kusankar,

Thanks for the reply,

1. Security-Levels are as following

VLAN 1 (inside) = 100

VLAN 2 (outside) = 0

VLAN 3 (SVRGRP_1) = 90

VLAN 4 (SVRGRP_2) = 80

2. nat-control is enabled; should I disabled it and what steps are required in e.g. restart firewall or clear xlate or something else ?

3. when I ping from vlan 3 to vlan 4 or vice versa I get error 305005 and if I configure nat according to 305005 recommended action I get error 305006

http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/system/message/logmsgs.html#wp1280900

4. No I have not yet configured a static translation because I thought if I do this configuration then I will end up ping from vlan 3 host to vlan 4 host on there real IPs instead of there mapped IPs.

Re: Configuring FWSM on 6509

Kureli Sankar — Fri, 15 Oct 2010 12:27:27 GMT

Pls. configure the static translation that I provided and try the ping using the real address on the other interface and vice versa. It should work.

If you turn off nat-control there is no need for a reboot and there is no need for the identity static that I suggested either.

Let us know.

-KS

Re: Configuring FWSM on 6509

zulqurnain — Fri, 15 Oct 2010 15:37:37 GMT

Hi Kusankar,

I'll try it out; but would it be possible that I can ping the host in vlan 4 from vlan 3 or vice versa on their mapped IPs, instead of real IPs.

I mean the same way when inside users or other LAN users are able to ping host in vlan 3 & 4 on their mapped IPs.

I hope I am clear in explaning the objectives.

Re: Configuring FWSM on 6509

zulqurnain — Sat, 16 Oct 2010 10:24:25 GMT

Hi Kusankar,

1st I configured the static as you said and I counld'nt not ping from SVRGRP_1 host to SVRGRP_2 host

2nd I removed the nat-control and I still counld'nt ping from SVRGRP_1 host to SVRGRP_2 host

3rd I removed the static which I configued 1st and ping from SVRGRP_1 host to SVRGRP_2 host, I was able to successfully BUT only on there real IPs and not the mapped IPs

how can I be able to ping from SVRGRP_1 host to SVRGRP_2 host on mapped IP , whereas SVRGRP_1 has higher security-level.

Re: Configuring FWSM on 6509

Kureli Sankar — Sat, 16 Oct 2010 12:55:19 GMT

1st I configured the static as you said and I counld'nt not ping from SVRGRP_1 host to SVRGRP_2 host

>>By using what IP address? The mapped IP right?

Pls. make it a habit to ping and address hosts within your network only by their real IPs as best as possible. The mapped IP is for people in the internet to reach your servers hosting web or e-mail or other services.

The static that I gave you is correct. You should be able to ping between vlan 3 and vlan 4 using the real ip address of the servers.

If you still insist on reaching the servers using their mapped IP from the inside then you need to look into what is called DNS re-write. There are some preq. for that - which is to enable dns inspection and dns request from the client pc should go through this FWSM and all that stuff.

My suggestion would be to try to access the servers using their real ip. This is best practice.

-KS

Re: Configuring FWSM on 6509

zulqurnain — Sat, 16 Oct 2010 15:41:36 GMT

Hi,

Once I configured the static, I was not able to ping or either IPs real or mapped. I was only able to ping when was without your static and I removed the nat-control but this ping was only happening on real IPs .

I agree with your comment that it is best practise to ping on real IPs rather then mapped IPs but we have some limitation due to which I am asked to achieve this objective that not only LAN users be able to ping hosts in SVRGRP_1 and SVRGRP_2 to their mapped IPs but also between they are able to do so to each on mapped rather then real IP.

I am positive that their should be a way to achieve it , it's just I can't make it possible.

Re: Configuring FWSM on 6509

Kureli Sankar — Sat, 16 Oct 2010 16:15:39 GMT

1. Was the access-list allowing icmp from source to dest? I think so or you wouldn't have been able to ping without nat-control and no statics.

2. is icmp inspection enabled? - with this you don't have to allow replies with an acl applied on the interface.

3. Now, when it breaks with identity static going from high to low security interface what do the logs say?

conf t

logging on

logging bufffered 7

exit

sh logg | i x.x.x.x

where x.x.x.x is either the source or dest. of the pings. Try to see tcp flow would work. Try RDC or http.

4. Now, trying to access the mapped IP from the inside, you need to add destination NAT for that. It is a little tricky to get this to work. We almost have to be on the box configuring the lines and watching the logs. It may take a long time getting this accomplished via the support forum. I suggest you open a TAC case so, we can look at this for you.

Here is a sample if you want to give it a shot.

inside host (10.1.1.1) ---FWSM---router--Interter

DMZ (webserver 192.168.1.1 translation to 1.1.1.1 on the internet)

For the inside host 10.1.1.1 to access the DMZ server using his private address 1921.68.1.1 you just need the following:

static (inside,dmz) 10.1.1.0 10.1.1.0 net 255.255.255.0

For the inside host 10.1.1.1 to access the DMZ server using the address 1.1.1.1 you need the following in addition to the above.

static (dmz,inside) 1.1.1.1 192.168.1.1 netmask 255.255.255.255

Again, my suggestion would be to open a TAC case if this doesn't work for you as these kind of issues may take a lot longer to solve via e-mail or posts.

-KS

Re: Configuring FWSM on 6509

zulqurnain — Sun, 17 Oct 2010 07:41:36 GMT

HI Kusankar,

"
inside host (10.1.1.1) ---FWSM---router--Interter
                                          |
                                 DMZ (webserver 192.168.1.1 translation to 1.1.1.1 on the internet)
For the inside host 10.1.1.1 to access the DMZ server using his private address 1921.68.1.1 you just need the following:
static (inside,dmz) 10.1.1.0 10.1.1.0 net 255.255.255.0
For the inside host 10.1.1.1 to access the DMZ server using the address 1.1.1.1 you need the following in addition to the above.
static (dmz,inside) 1.1.1.1 192.168.1.1 netmask 255.255.255.255
"

The above I am very comfortable working in and have already achived, if you read my first post, what I have been asking is if I want DMZ_1 host accessing DMZ_2 host using the address 1.1.1.1 as example 2 , knowning DMZ_1 has higher or equal security-level configured.

I will open a TAC case also; but it will be some time as my PICA access has some problem and I need to contact our local support in order to grant me once again the requested access for opening TAC on my ID. untill then if you can help me I would appercaite.

Re: Configuring FWSM on 6509

Kureli Sankar — Sun, 17 Oct 2010 13:19:46 GMT

Follow this forumla:

source identity nat goes from high to low:

static (high,low) high_security_net high_security_net netmask 255.255.x.x

This will provide source address translation for all hosts on the high security subnet e when they go to a lower security interface.

destination nat goes low to high:

static (low,high) mapped_ip real_ip_in_low net 255.255.255.255

This dest nat will receive packets on the high security interface destined to the mapped_ip and send it to the real ip in the lower security interface.

You can fill in the interface names and IP addresses in the above static lines.

When you have all diff. interfaces wanting to do this to all other interfaces this could get ugly. This is the reason for mentioning best practice.

-KS