02-03-2014 04:10 AM - edited 03-11-2019 08:39 PM
Hi All,
I have the following configured on my ASA, I've only put in what's relevant. There's not really much else on it anyways.
At the moment I believe all traffic is being NAT'd on the 192.168.127.x and 192.168.128.x /24 networks when going outside
I want to however allow the subnets above in bold to access the inside network of 172.27.100.0 /22 (off of Gi0/1), and basically not have the ASA try to NAT this.
What do I need to add?
Thanks
!
interface GigabitEthernet0/0
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/0.127
vlan 127
nameif Vlan127
security-level 50
ip address 192.168.127.1 255.255.255.0
!
interface GigabitEthernet0/0.128
vlan 128
nameif Vlan128
security-level 50
ip address 192.168.128.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 172.27.100.160 255.255.252.0
!
interface GigabitEthernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/4
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/5
nameif outside
security-level 0
ip address Public IP 255.255.255.0
!
interface Management0/0
nameif management
security-level 100
ip address 10.44.240.190 255.255.255.0
management-only
!
dns domain-lookup inside
dns server-group DefaultDNS
name-server 10.44.241.50
name-server 10.44.241.51
domain-name Test.com
same-security-traffic permit inter-interface
object-group network DynamicNatInside
network-object 192.168.127.0 255.255.255.0
network-object 192.168.128.0 255.255.255.0
access-list Inside_To_Out extended permit ip object-group DynamicNatInside any
pager lines 24
logging asdm informational
mtu Vlan127 1500
mtu Vlan128 1500
mtu inside 1500
mtu outside 1500
mtu management 1500
icmp unreachable rate-limit 1 burst-size 1
icmp permit any inside
icmp permit any outside
asdm image disk0:/asdm-66114.bin
no asdm history enable
arp timeout 14400
!
nat (any,outside) after-auto source dynamic DynamicNatInside interface
access-group Inside_To_Out out interface outside
route outside 0.0.0.0 0.0.0.0 “PUBLIC IP”
route inside 172.16.0.0 255.240.0.0 172.27.100.10
Solved! Go to Solution.
02-03-2014 05:17 AM
Hi,
If Vlan127 and Vlan128 should only access external networks and only specific resources on the internal network then you will have to build an ACL for each of the interfaces that first allows the specific traffic to the internal network that you need and then blocks all other traffic to the internal networks and finally allows all traffic.
The configuration depends mainly on how many Internal networks there are to which these Vlan127 and Vlan128 should not be able to access.
If your internal network fits into the network 172.16.0.0/12 and traffic needs to be allowed to network 172.27.100.0/24 then you could configure the ACL in this way for example
access-list VLAN-127-IN remark Allow specific traffic
access-list VLAN-127-IN permit tcp 192.168.127.0 255.255.255.0 172.27.100.0 255.255.255.0
access-list VLAN-127-IN remark Deny traffic to rest of the Internal network
access-list VLAN-127-IN deny ip any 172.16.0.0 255.240.0.0
access-list VLAN-127-IN remark Allow all other traffic
access-list VLAN-127-IN permit ip 192.168.127.0 255.255.255.0 any
access-group VLAN-127-IN in interface Vlan127
access-list VLAN-128-IN remark Allow specific traffic
access-list VLAN-128-IN permit tcp 192.168.128.0 255.255.255.0 172.27.100.0 255.255.255.0
access-list VLAN-128-IN remark Deny traffic to rest of the Internal network
access-list VLAN-128-IN deny ip any 172.16.0.0 255.240.0.0
access-list VLAN-128-IN remark Allow all other traffic
access-list VLAN-128-IN permit ip 192.168.128.0 255.255.255.0 any
access-group VLAN-128-IN in interface Vlan128
In the above ACLs you would have to make sure that you add any rules that allow traffic to the internal networks to the top of the ACL or atleast before the "deny" statement. This will let you allow the traffic you need but block all other traffic to the internal network. Internet connections will still be allowed by the last rule. (If we didnt have the "deny" rule in between the last rule would allow traffic to internal networks).
The way the ACLs look in your setup might naturally vary on the above.
Hope this helps
- Jouni
02-03-2014 04:38 AM
Hi,
So basically you want the 2 LAN/DMZ networks to talk with another LAN network?
If this is the case then you should not need any NAT configurations at all.
The Dynamic PAT configuration you have only applies to traffic that is headed through the "outside" interface according to the routing table.
Notice however that you have "security-level 50" on both of the source interfaces (Vlan127 and Vlan128) and the destination interface has "security-level 100"
This means you have to configure ACL for both of these interface to allow the traffic from them to the destination network. Notice also that as soon as you configure the interface ACL to these interface it will then control the traffic. So make sure you also allow traffic to external network and where ever they need to connect at the moment.
Hope this helps
- Jouni
02-03-2014 05:07 AM
Hi Jouni,
VLAN 127 / 128 Interfaces are for Internet access only, hence the NAT to the Outside. However I need them to also be able to access some specific Internal resources Local to the Inside Interface.
E.G if I wanted the 192.168.127.0 /24 to access say 172.27.100.0 /24 only, should I create object groups or do I just need ACL?
e.g would this be suffice
access-list TEST extended permit tcp 192.168.127.0 255.255.255.0 172.27.100.0 255.255.255.0
Do I need to then assign this to an Interface?
02-03-2014 05:17 AM
Hi,
If Vlan127 and Vlan128 should only access external networks and only specific resources on the internal network then you will have to build an ACL for each of the interfaces that first allows the specific traffic to the internal network that you need and then blocks all other traffic to the internal networks and finally allows all traffic.
The configuration depends mainly on how many Internal networks there are to which these Vlan127 and Vlan128 should not be able to access.
If your internal network fits into the network 172.16.0.0/12 and traffic needs to be allowed to network 172.27.100.0/24 then you could configure the ACL in this way for example
access-list VLAN-127-IN remark Allow specific traffic
access-list VLAN-127-IN permit tcp 192.168.127.0 255.255.255.0 172.27.100.0 255.255.255.0
access-list VLAN-127-IN remark Deny traffic to rest of the Internal network
access-list VLAN-127-IN deny ip any 172.16.0.0 255.240.0.0
access-list VLAN-127-IN remark Allow all other traffic
access-list VLAN-127-IN permit ip 192.168.127.0 255.255.255.0 any
access-group VLAN-127-IN in interface Vlan127
access-list VLAN-128-IN remark Allow specific traffic
access-list VLAN-128-IN permit tcp 192.168.128.0 255.255.255.0 172.27.100.0 255.255.255.0
access-list VLAN-128-IN remark Deny traffic to rest of the Internal network
access-list VLAN-128-IN deny ip any 172.16.0.0 255.240.0.0
access-list VLAN-128-IN remark Allow all other traffic
access-list VLAN-128-IN permit ip 192.168.128.0 255.255.255.0 any
access-group VLAN-128-IN in interface Vlan128
In the above ACLs you would have to make sure that you add any rules that allow traffic to the internal networks to the top of the ACL or atleast before the "deny" statement. This will let you allow the traffic you need but block all other traffic to the internal network. Internet connections will still be allowed by the last rule. (If we didnt have the "deny" rule in between the last rule would allow traffic to internal networks).
The way the ACLs look in your setup might naturally vary on the above.
Hope this helps
- Jouni
02-03-2014 11:44 PM
Hi Jouni,
I'll be in a position to test this later today, will keep you posted,
Thanks again!
02-04-2014 07:22 AM
Hi Jouni,
Got this working to an extent.
Clients can get a DHCP address and access the Internet OK.
However when on a client PC in Vlan 127 with address of say 192.168.127.30 - I am still unable to ping anything on the network 172.27.100.0 /22. Maybe ICMP replies are not allowed in?
ACL seems to be getting hit -
access-list VLAN-127-IN; 3 elements; name hash: 0x6431f2
access-list VLAN-127-IN line 1 remark Allow Specific Traffic
access-list VLAN-127-IN line 2 extended permit ip 192.168.127.0 255.255.255.0 172.27.100.0 255.255.252.0 (hitcnt=18) 0x01be4d65
access-list VLAN-127-IN line 3 remark Deny traffic to rest of internal network
access-list VLAN-127-IN line 4 extended deny ip any 172.16.0.0 255.240.0.0 (hitcnt=0) 0x56f115a5
access-list VLAN-127-IN line 5 remark Allow all other traffic
access-list VLAN-127-IN line 6 extended permit ip 192.168.127.0 255.255.255.0 any (hitcnt=48) 0xfd6fe6c2
I have the following configured as you described.
access-list VLAN-127-IN remark Allow Specific Traffic
access-list VLAN-127-IN extended permit ip 192.168.127.0 255.255.255.0 172.27.100.0 255.255.252.0
access-list VLAN-127-IN remark Deny traffic to rest of internal network
access-list VLAN-127-IN extended deny ip any 172.16.0.0 255.240.0.0
access-list VLAN-127-IN remark Allow all other traffic
access-list VLAN-127-IN extended permit ip 192.168.127.0 255.255.255.0 any
02-04-2014 07:29 AM
Hi,
Have you made sure that the actual destination hosts dont just accept the ICMP?
I don't think you should need the configure ICMP Inspection in this case but I am not completely sure.
Do you have the basic "policy-map" configured?
show run policy-map
And if you do, do you have "inspect icmp" and "inspect icmp error" configured under there?
I guess you could also confirm this with "packet-tarcer"
packet-tracer input Vlan127 icmp
I presume also that all devices on network 172.27.100.0/22 use the ASA as their default gateway? I also presume that the Vlan127 network hosts use their ASA interface as their gateway?
I am just wondering if there is a possibility that the network topology is so that traffic flow isnt what I would expect.
- Jouni
02-04-2014 07:42 AM
Hi,
Please see below. Not sure if this helps.
packet-tracer input vlan127 icmp 192.168.127.1 ?
<0-255> Enter the icmp type
packet-tracer input vlan127 icmp 192.168.127.1 8 0 ?
<0-65535> Enter the icmp identifier
A.B.C.D Enter the destination ipv4 address
fqdn Enter this keyword if an FQDN is specified as destination address
packet-tracer input vlan127 icmp 192.168.127.1 8 0 172.27.102$
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.27.100.0 255.255.252.0 inside
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: Vlan127
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
02-04-2014 07:48 AM
Hi,
You used the ASAs interface IP address as the source. This will always fail. Use some random source address from the network 192.168.127.0/24
Also, can you confirm that both the source and destination network use the ASA as their default gateway? I mean both the source and destination network are directly connected to the ASA but the "route" configuration suggest that you have some router(s) in your LAN so I just want to make sure that the hosts are forwarding the traffic to the ASA first when they are connecting to another network.
- Jouni
02-04-2014 10:01 AM
Hi Jouni,
The networks vlan 127 and 128 are trying to access (172.27.100.0 /22) sit behind the ASA gig0/1 interface. Those networks use my core switch as the DG. The Vlans 127 and 128 only use the ASA as the DG. I'm heading back to the office later to run some further testing. I'm guessing traffic from the core would need a route to the 192.168.127.x network through my gig0/1 interface.
02-04-2014 10:08 AM
Hi,
Ok, so the network 172.27.100.0/22 has its user gateway on the core switch.
Does the core switch have any Vlan interface configured either to network 192.168.127.0/24 or network 192.168.128.0/24?
Just wondering as this would cause problems atleast for TCP traffic as the traffic would be forwarded asymmetrically. This would be because networks 172.27.100.0/22 connections would come to the core switch first and if it had an IP address on some interface belonging to Vlan127/Vlan128 it would simply pass traffic to the host directly and the host would reply through the ASA and ASA would drop the TCP traffic.
To my understanding other than for the interface ACLs your original configuration for the ASA already contained everything needed for these networks to "talk with each other".
If there is still problems then might have to look at the core if the situation is as I described or have a look at the current configuration of the ASA just to be sure.
- Jouni
02-04-2014 11:04 AM
OK,
Back in the office to look at this. Progress..kinda
From a client who is on VLAN127 I can ping 172.27.100.10 which is the SVI on the CORE. I have also pasted the output of packet-tracer below for this.
packet-tracer input vlan127 icmp 192.168.127.10 8 0 172.27.100.10
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.27.100.0 255.255.252.0 inside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group VLAN-127-IN in interface Vlan127
access-list VLAN-127-IN extended permit ip 192.168.127.0 255.255.255.0 172.27.100.0 255.255.252.0
access-list VLAN-127-IN remark Deny traffic to rest of internal network
Additional Information:
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 511, packet dispatched to next module
Result:
input-interface: Vlan127
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
However from the same client I cannot ping say 172.27.100.66 which I know is online. So I can ping the Core SVI but not any hosts on that network.
Packet Tracer for that one below.
packet-tracer input vlan127 icmp 192.168.127.10 8 0 172.27.100.66
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.27.100.0 255.255.252.0 inside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group VLAN-127-IN in interface Vlan127
access-list VLAN-127-IN extended permit ip 192.168.127.0 255.255.255.0 172.27.100.0 255.255.252.0
access-list VLAN-127-IN remark Deny traffic to rest of internal network
Additional Information:
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 513, packet dispatched to next module
Result:
input-interface: Vlan127
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
02-04-2014 11:55 AM
Hi Jouni,
This actually seems to be working now as I'd expect with regards to the networks accessing each other.
One last question - do I need to have an ACL "Inbound" on the outbound interface to prevent attacks or is the ASA acting as stateful and only allowing traffic back in which went out orginally?
02-04-2014 12:25 PM
Hi,
You will only need the INBOUND ACL for an interface to control connections initiated from network behind that interface.
You should probably only configure INBOUND ACLs but as I mentioned their purpose is to control the initial connection attempt but not the return traffic. As you said, the ASA is a stateful firewall and will therefore keep track of the connections it has already allowed through the firewall and allow the return traffic for those connection automatically.
One exeption that I could point out that is very common problem is that ICMP Inspection is not enabled by default. This results in the fact that ICMP from LAN to WAN will usually fail as the return traffic wont get through. (As its not inspected) The solution in this case is usually to enable the ICMP Inspection and you would also have the option to configure that INBOUND ACL on the EXTERNAL interface to allow the ICMP return messages like Echo Reply, Time Exceeded and Unreachable.
You dont necesarily need to configure any ACL on the EXTERNAL interface unless you do have Static NAT / Static PAT configured for some hosts and need to allow connections. Without any ACL on the EXTERNAL interface it will simply block INBOUND connections.
Hope this helps
- Jouni
02-04-2014 10:05 AM
Or would it be better to create another sub int for vlan 1 under gig0/0 so traffic routes out same interface?
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