Cisco ASA Inter-Vlan Access from Security Level 50 to Security Level 100

[bradnmarsha]

I have a Corporate Vlan (vlan1) or (inside) security level  and a Guest Vlan (vlan100) or (public). My ASA is running a 8.2 image. On my inside Vlan I have  static nat going to a server for http access. {static (inside,outside) X.X.X.X 192.168.1.30 netmask 255.255.255.255}  access-list outside extended permit tcp any host X.X.X.X eq www. This NAT works fine. However anyone on the guest network is unable to access server at the public IP. I found a article similar to this http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html#problem  This is not working though. I am now able to ping the site from the guest but I still cannot access through http. I only want the guest Vlan to be able to access this site on the Corporate Vlan and nothing else. Below is what I have

interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.254.0 standby 192.168.1.2

interface GigabitEthernet0/1.100
 vlan 100
 nameif public
 security-level 50
 ip address 192.168.100.1 255.255.255.0 standby 192.168.100.2

access-list outside extended permit tcp any host 9.10.11.12 eq www
access-list outside extended permit tcp any host 9.10.11.12 eq citrix-ica
access-list outside extended permit tcp any host 9.10.11.12 eq 1080
access-list outside extended permit tcp any host 9.10.11.12 eq https
access-list outside extended permit tcp any host 9.10.11.12 eq 2598
access-list outside extended permit tcp any host 9.10.11.12 eq 8080

access-list outside extended permit tcp 192.168.100.0 255.255.255.0 host 9.10.11.12 eq www
access-list outside extended permit tcp 192.168.100.0 255.255.255.0 host 192.168.1.30 eq www

access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 9.10.11.12 eq www
access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 192.168.1.30 eq www
access-list acl_public extended deny ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.254.0
access-list acl_public extended deny ip any object-group spotify
access-list acl_public extended permit ip any any

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0

nat (public) 1 0.0.0.0 0.0.0.0

static (inside,outside) 9.10.11.12 192.168.1.30 netmask 255.255.255.255

static (inside,public) 9.10.11.12 192.168.1.30 netmask 255.255.255.255

static (public,outside) 9.10.11.12 192.168.1.30 netmask 255.255.255.255 dns

[Jon Marshall]

I don't think your issue is DNS doctoring because your server is on the inside.

As far as i can tell you don't need your last static entry and the one above it "static(inside,public) ..." should do the job.

You need DNS doctoring when the packet is routed to the wrong interface. So looking at the document the issue is the client on the inside sends a packet to the public IP which is routed to the outside interface and then redirected back in because of the static statement.

But you don't have that problem

A client on the public vlan sends a packet to the public IP and your static statement translates that back to the inside IP and should just forward it to the server as far as i can see.

I presume you tried it without the additional static using the "dns" keyword and it didn't work ?

Jon

[bradnmarsha]

That is correct I actually tried that 1st and it didn't work. I initially thought all I needed was 

static (inside,public) 9.10.11.12 192.168.1.30 netmask 255.255.255.255

access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 9.10.11.12 eq www

I haven't had the client test recently since I change the access list from 

access-list acl_public extended deny ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.254.0
access-list acl_public extended deny ip any object-group spotify
access-list acl_public extended permit ip any any

access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 9.10.11.12 eq www

to 

access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 9.10.11.12 eq www
access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 192.168.1.30 eq www
access-list acl_public extended deny ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.254.0
access-list acl_public extended deny ip any object-group spotify
access-list acl_public extended permit ip any any

But I always thought on ASAs that the access-list didn't read like a router from top to bottom but I may be wrong on that. 

There is a static nat in the ASA for the whole public network going into the corporate network (static (inside,public) 10.1.0.0 10.1.0.0 netmask 255.255.254.0) and then the access list blocks all the traffic (access-list acl_public extended deny ip 192.168.50.0 255.255.255.0 10.1.0.0 255.255.254.0) Which I dont understand the point in since they are on different security levels then they are not able to pass traffic from the public to the Corporate anyway.

Right now this is all I have related to the NAT with the access lists that are on it. Does anyone see any issue as to why this wouldn't work?

access-list outside extended permit tcp any host 9.10.11.12 eq www
access-list outside extended permit tcp any host 9.10.11.12 eq citrix-ica
access-list outside extended permit tcp any host 9.10.11.12 eq 1080
access-list outside extended permit tcp any host 9.10.11.12 eq https
access-list outside extended permit tcp any host 9.10.11.12 eq 2598
access-list outside extended permit tcp any host 9.10.11.12 eq 8080

access-list acl_public extended permit tcp 192.168.50.0 255.255.255.0 host 9.10.11.12 eq www
access-list acl_public extended deny ip 192.168.50.0 255.255.255.0 192.168.1.0 255.255.254.0
access-list acl_public extended deny ip any object-group spotify
access-list acl_public extended permit ip any any

access-list acl_inside extended deny ip any object-group spotify
access-list acl_inside extended permit ip any any

global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
nat (public) 1 0.0.0.0 0.0.0.0
static (inside,public) 192.168.1.0 192.168.1.0 netmask 255.255.254.0
static (inside,public) 9.10.11.12 192.168.1.30 netmask 255.255.255.255

[Jon Marshall]

As far as i know acls are processed in order just like IOS acls otherwise you would not be able to permit certain things, deny others and then permit any.

Your first acl before you made the change wouldn't really wouldn't affect it because the deny line is to 192.168.1.0/23 and with pre 8.3 ASA you don't use the translated address in acls ie. you would use the real IP so the "permit ip any any" should have allowed it through.

There appear to be typos though in your last post as it is referencing 192.168.50.0/24 but there is no mention of that in your first post.

I can't see why what you have wouldn't work.

Really obvious question but the public acl, it has been applied to the interface hasn't it ?

Jon

[bradnmarsha]

Yes there is a Typo in the post but not in the ASA I forgot to change that part of the IP please consider anything that has a 192.168.50.0/24 as a 192.168.100.0/24 and anything with 10.1.0.0/23 as a 192.168.0.0/23. Sorry that was my bad

[bradnmarsha]

Yes it has I probably should have added that to the config. But I haven't had a chance to test the config since I changed the ACL so  it may work now being that the 1st acl would have been (access-list acl_public extended deny ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.254.0) then it never made it to the (access-list acl_public extended permit tcp 192.168.100.0 255.255.255.0 host 9.10.11.12 eq www). I have that changed now so I hope it will work. 

access-group acl_public in interface public

[Jon Marshall]

Sorry to say but i doubt that will make a difference.

I explained it the wrong way round in my other post when I said real IP I actually meant the translated IP.

The real IP is the actual address of your server.

So pre 8.3 ASA your acls always use the translated IP not the real IP so that first line would have no effect because that was not the destination IP address when it was checked against the acl.

Post 8.3 it would have had an effect.

So I doubt that change will make it work.

Jon