10-16-2013 01:10 AM - edited 03-11-2019 07:52 PM
I have a ASA 5505 with the base lisence. I have configured 3 VLANs, one for the outside, one for the office and one for the guest wifi. I cannot get the guest VLAN to communicate with the office VLAN. There is a server I am hosting in the guest WiFi that I would like to be able to access from the office VLAN for administration.
I have attached my current running config, I have played around with it a lot and could not get anything to work for me.
Guest VLAN: 192.168.0.0/24 Security level 50 Server IP: 192.168.0.14
Office VLAN: 10.0.0.0 /24 Security level 100 My office machine: 10.0.0.5
3rd VLAN (security level 0) is the WAN connection, both VLANs have an internet connection, but I just cannot get the two to talk to each other. It is my understanding that a higher security level interface can initiate communication with a lower security interface, but that is just not happening here.
Thank you in advance.
Solved! Go to Solution.
10-16-2013 02:02 AM
Hi,
Seems to me that the "no forward interface" command is already set correctly.
I mean its set so that no connection from WAN to WLAN are allowed because of the license limitation and seems that this is not an issue at the moment or even a requirement?
With the attached configuration it would seem to me that both networks should be able to communicate.
You could add a NAT
static (office,WLAN) 10.0.0.0 10.0.0.0 netmask 255.255.255.0
And then try the connections again
IF you need to host the server from WLAN to the WAN then you would need the additional license as mentioned by Alain above.
- Jouni
10-16-2013 01:58 AM
Hi,
if you want the 3 VLANs to communicate without restriction you need a security licence.
If you do this then the Guest VLAN won't be able to initiate connection to the Office VLAN but will reply to connection initiated by the Office VLAN:
interface Vlan21
no forward interface vlan 1
Also get rid of the no forward command on VLAN11.
Regards.
Alain
Don't forget to rate helpful posts.
10-16-2013 02:02 AM
Hi,
Seems to me that the "no forward interface" command is already set correctly.
I mean its set so that no connection from WAN to WLAN are allowed because of the license limitation and seems that this is not an issue at the moment or even a requirement?
With the attached configuration it would seem to me that both networks should be able to communicate.
You could add a NAT
static (office,WLAN) 10.0.0.0 10.0.0.0 netmask 255.255.255.0
And then try the connections again
IF you need to host the server from WLAN to the WAN then you would need the additional license as mentioned by Alain above.
- Jouni
10-16-2013 03:47 AM
Hi,
I don't see the point of doing a no forward from WAN to WLAN because WAN won't be able to communicate with WLAN anyway because the security level is lower on the WAN side. Also the ASA will forward traffic from high to low without any NAT needed as no nat-control is the default so I wonder how an identity NAT would solve the problem unless there was another routing hop involved and there was no routing information but that doesn't seem to be the case.
Regards
Alain
Don't forget to rate helpful posts.
10-16-2013 05:18 AM
Hi,
I think with Base License you can only activate the 3rd Vlan if you have it configured with "no forward interface" command. I dont think you can use the 3rd interface unless one interface of the 3 has this configuration.
In this case the connections were between "office" and "WLAN" so it seemed to me to be the most logical choice to use the "no forward interface" command from WAN to WLAN as its configured at the moment.
I have a couple of Base License ASA5505 at home and the above setup is actually exactly the way I have done my interface setup. I have a LAN and WLAN and WAN interfaces and WAN interface holds the "no forward interface Vlanx" which limits traffic from WAN to WLAN. I did this configuration because I dont want to limit traffic between WLAN and LAN and also dont have any need for anyone to connect from WAN to WLAN since there are but wireless devices there. And considering the Base License requirement this was pretty much the only choice to achieve what I wanted.
With regards to the NAT,
I have already forgotten a lot of the "minor" things with the older NAT format but it would seem to me that even with a firewall that has "no nat-control" configured and there is only a "nat" statement for certain ID number but no matching ID "global" to the destination interface that the packet will be dropped because it matched the "nat" statement but didnt find the matching "global"
For example
interface GigabitEthernet0/1.7
vlan 7
nameif DESTINATION
security-level 0
ip address 10.54.7.1 255.255.255.0 standby 10.54.7.254
interface GigabitEthernet0/1.2500
vlan 2500
nameif SOURCE
security-level 50
ip address x.x.x.x 255.255.255.240 standby x.x.x.y
There is a network behind interface SOURCE which connects to the directly connected network 10.54.7.0/24. There only a matching "nat" statement for the source network but no matching "global" for the destination interface. There are no "static" configurations between these interfaces. The "no nat-control" setting is configured
FW# sh run nat-control
no nat-control
nat (SOURCE) 1 10.21.0.0 255.255.0.0
packet-tracer input SOURCE tcp 10.21.1.1 12345 10.54.7.100 80
This end with a DROP at the NAT Phase
Phase: 7
Type: NAT
Subtype:
Result: DROP
Config:
nat (SOURCE) 1 10.21.0.0 255.255.0.0
match ip SOURCE 10.21.0.0 255.255.0.0 DESTINATION any
dynamic translation to pool 1 (No matching global)
translate_hits = 2, untranslate_hits = 0
Additional Information:
The above was the reason I was suggesting the Static Identity NAT at this point as I didnt see anything wrong with the configuration otherwise
- Jouni
10-16-2013 05:54 AM
Hi,
I think with Base License you can only activate the 3rd Vlan if you have it configured with "no forward interface" command. I dont think you can use the 3rd interface unless one interface of the 3 has this configuration.
In this case the connections were between "office" and "WLAN" so it seemed to me to be the most logical choice to use the "no forward interface" command from WAN to WLAN as its configured at the moment.
Yes I agree with the 3rd VLAN restriction and your answer makes sense.
Concerning NAT:
global (WAN) 1 interface
nat (office) 1 10.0.0.0 255.255.255.0
nat (WLAN) 1 192.168.0.0 255.255.255.0
So it seems this is correct, office and wlan are natted on WAN so as nat-control is disabled then there shouldn't need any static identity NAT to make it work here as far as I know.
Regards
Alain
Don't forget to rate helpful posts.
10-16-2013 06:07 AM
Hi,
This section from the 8.2 software Configuration Guide seems to point to the situation I am seeing on the firewall where I tested the above example
Configuration Examples for NAT Control
When NAT control is disabled with the no-nat control command, and a NAT and a global command pair are configured for an interface, the real IP addresses cannot go out on other interfaces unless you define those destinations with the nat 0 access-list command.
For example, the following NAT is the that one you want performed when going to the outside network:
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 209.165.201.2The above configuration catches everything on the inside network, so if you do not want to translate inside addresses when they go to the DMZ, then you need to match that traffic for NAT exemption, as shown in the following example:
access-list EXEMPT extended permit ip any 192.168.1.0 255.255.255.0access-list EXEMPT remark This matches any traffic going to DMZ1access-list EXEMPT extended permit ip any 10.1.1.0 255.255.255.0access-list EXEMPT remark This matches any traffic going to DMZ1nat (inside) 0 access-list EXEMPTAlternately, you can perform NAT translation on all interfaces:
nat (inside) 1 0.0.0.0 0.0.0.0global (outside) 1 209.165.201.2global (dmz1) 1 192.168.1.230global (dmz2) 1 10.1.1.230
What the above doesnt mention though that you can avoid the situation with the Static Identity NAT also after which the matching "nat" statement wont be a problem anymore.
I guess we need to wait for Chip to get back to us whether the Static Identity NAT helped or not and if needed troubleshoot furhter
- Jouni
10-16-2013 09:38 AM
I was not able to ping or access the webpage on the server with the following set:
static (office,WLAN) 10.0.0.0 10.0.0.0 netmask 255.255.255.0
Thank you,
Chip
10-16-2013 09:43 AM
Hi,
Could you issue the command
packet-tracer input office tcp 10.0.0.5 12345 192.168.0.14 80
It should test the ASA configurations. Depending on what you are going to use to manage the server you can change the port above although for this tests purpose it shouldnt matter.
Post the output of the above command here.
Have you confirmed that the server is listening on the port that you are attempting the connection?
- Jouni
Message was edited by: Jouni Forss (Changed the destination port in the command)
10-16-2013 10:51 AM
10-16-2013 11:07 AM
Hi,
I presume you mean that you can access the server when you connect to it from the local WLAN network? Is it still unreachable from the OFFICE network?
The "packet-tracer" goes through just fine and matches the "static" configuration I suggested.
If connections from OFFICE to WLAN server are still not working then the next step for me would be to check the network settings on the actual server. A possible reason for not reaching the server from the OFFICE network would be if the WLAN network server is not configured with default gateway or is configured with wrong default gateway. This would explain the fact that the server could be reached from the same WLAN network (doesnt need to use default gateway) but could not be reached from another network (needs defaulte gateway to forward the return traffic back to ASA and to the OFFICE user)
- Jouni
10-16-2013 01:29 PM
Alright, I got to the root of the problem. I took out the server and attached a normal host and was able to access it with the identity NAT rules. I've narrowed the issue down to the server, It's not accepting requests from addresses outside of it's own network. I will have to troubleshoot that, but as far as network connectivity, the 2 VLANs are able to talk to one another now.
Quick question, is there way to limit a just a specific host from one VLAN to only talk to one other host on the other VLAN with this NAT rule? Or will that have to be done through ACLs?
EDIT: Sorry, got ahead of myself. I set up the static NAT rules with a /32 netmask and that seemed to do the trick.
Thank you,
Chip
10-16-2013 01:43 PM
Hi,
The traffic controlling is best done through the ACL while keeping the NAT as simple as possible.
Lets say your requirement are the following
Then if your ACL configuration is still the same as the one in the attached configuration you could do these additions
access-list office line 1 remark Allow management access to WLAN network server
access-list office line 2 permit tcp host 10.0.0.5 host 192.168.0.14 eq 443
access-list office line 3 remark Deny all traffic from OFFICE to WLAN
access-list office line 4 deny ip any 192.168.0.0 255.255.255.0
access-list office line 5 remark Allow Internet traffic
access-list WLAN line 1 remark Deny all traffic from WLAN to OFFICE
access-list WLAN line 2 deny ip any 10.0.0.0 255.255.255.0
access-list WLAN line 3 remark Allow Internet traffic
After the additions your ACL should look like this (lines marked red are those which we added)
access-list office remark Allow management access to WLAN network server
access-list office permit tcp host 10.0.0.5 host 192.168.0.14 eq 443
access-list office remark Deny all traffic from OFFICE to WLAN
access-list office deny ip any 192.168.0.0 255.255.255.0
access-list office remark Allow Internet traffic
access-list office extended permit ip any any
access-list WLAN line 1 remark Deny all traffic from WLAN to OFFICE
access-list WLAN line 2 deny ip any 10.0.0.0 255.255.255.0
access-list WLAN line 3 remark Allow Internet traffic
access-list WLAN extended permit ip any any
So in short the connection you need to the WLAN network server from OFFICE host would be allowed. All other traffic would be blocked from forming from OFFICE to WLAN. Also all traffic from WLAN to OFFICE would be blocked.
Since you already have the "permit ip any any" in the existing ACLs and we insert the above ACL rules with line numbers to the top of the ACL means that Internet traffic from both WLAN and OFFICE networks would be allowed.
If you would need to allow some other traffic between the local networks you would simply add "permit" statements/rules to the top of the ACL or atleast before the "deny" statement/rules.
Hope this helps
Please do remember to mark a reply as the correct answer if it answered your question and/or rate helpfull answers.
Feel free to ask more if needed though
- Jouni
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide