03-04-2013 01:23 PM - edited 03-11-2019 06:09 PM
I have a 5520 in production at a customer's site between an outside 802.11 network and an inside server. The server can get to outside hosts OK, and the traffic is being NATed properly, and sockets initiated by the server on the inside can pass data both ways, but I need to allow outside hosts the ability to send 'announcement' UDP packets to the inside server. I thought this might be an outside-NAT-required issue to get the traffic routed, but I need the inside server to see the actual outside host source IP in the UDP packet, so I basically set the outside host up similar to the inside host, just without the NAT table on the firewall -- it's subnet is outside the destination (inside server) subnet, and its gateway is the outside interface of the ASA, the same way the inside server is able to get to hosts outside. The firewall should just route the packet with a destination of the inside subnet once it sees that it hits a 'permit' ACL.
I have the appropriate ACL's set up, and when I do 'show access-list' I see policy hits for the 'permit' statements where the outside host is generating the announcement and it's hitting the ACL. I even duplicated the ACL into list 101 and 102, and applied 101 for inbound traffic on the outside int, and applied 102 for outbound traffic on the inside int, and I'm seeing policy hits on both permit statements outside and inside, so it looks like the traffic is being passed on to the inside interface and permitted, but the server isn't seeing the packets.
I can ping the outside interface from the outside, but cannot ping the inside interface or any inside hosts from the outside, even though I have 'permit icmp any any' enabled on the ACL on both ints. When I remove the firewall and put the outside clients on the same subnet, the server sees the packets just fine.
I set up the same scenario in my lab with an ASA 5505, with the same results. Any ideas? Below is the running config from the 5505 in the lab. The production firewall is running a slightly older version of ASA, so I made the configuration as basic as possible on the 5505 to match the config in the field:
: Saved
:
ASA Version 8.3(1)
!
hostname ciscoasa
enable password Guh9Xxhb9mcC8lV1 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Vlan2
description Outside WAN Interface
nameif outside
security-level 0
ip address 192.168.10.1 255.255.255.0
!
interface Vlan3
description Inside LAN Interface
nameif inside
security-level 100
ip address 192.168.250.41 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 3
!
interface Ethernet0/1
switchport access vlan 2
!
interface Ethernet0/2
shutdown
!
interface Ethernet0/3
shutdown
!
interface Ethernet0/4
shutdown
!
interface Ethernet0/5
shutdown
!
interface Ethernet0/6
shutdown
!
interface Ethernet0/7
shutdown
!
ftp mode passive
access-list 101 remark -ACCESS LIST 101 APPLIED TO OUTSIDE-
access-list 101 remark -WAN to LAN-
access-list 101 remark --
access-list 101 remark -Allowed ICMP Pass-Thru-
access-list 101 remark ---
access-list 101 extended permit icmp any any echo-reply
access-list 101 extended permit icmp any any unreachable
access-list 101 extended permit icmp any any time-exceeded
access-list 101 extended permit icmp any any echo
access-list 101 remark ----
access-list 101 remark -DEFAULT - Permit outside hosts Announce to 192.168.250.24-
access-list 101 remark -----
access-list 101 extended permit udp any host 192.168.250.24 eq 54771
access-list 101 remark ------
access-list 101 remark -Deny all IP - Implicit, but done to trap hits-
access-list 101 remark ---------
access-list 101 extended deny ip any any
access-list 101 remark ----------
access-list 101 remark -ACL Added for FB2 UDP Discovery-
access-list 101 remark -Added on 2-28-13 by L.Pederson-
access-list 102 remark -ACCESS LIST 102 APPLIED TO INSIDE-
access-list 102 remark -WAN to LAN-
access-list 102 remark --
access-list 102 remark -Allowed ICMP Pass-Thru-
access-list 102 remark ---
access-list 102 extended permit icmp any any echo-reply
access-list 102 extended permit icmp any any unreachable
access-list 102 extended permit icmp any any time-exceeded
access-list 102 extended permit icmp any any echo
access-list 102 remark ----
access-list 102 remark -DEFAULT - Permit outside hosts Announce to 192.168.250.24-
access-list 102 remark -----
access-list 102 extended permit udp any host 192.168.250.24 eq 54771
access-list 102 remark --------
access-list 102 remark -Deny all IP - Implicit, but done to trap hits-
access-list 102 remark ---------
access-list 102 extended deny ip any any
access-list 102 remark ----------
access-list 102 remark -ACL Added for FB2 UDP Discovery-
access-list 102 remark -Added on 2-28-13 by L.Pederson-
pager lines 24
logging enable
logging monitor debugging
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
icmp permit any echo inside
icmp permit any unreachable inside
icmp permit any time-exceeded inside
asdm image disk0:/asdm-631.bin
asdm history enable
arp timeout 14400
nat (inside,outside) source dynamic any interface
access-group 102 out interface inside
access-group 101 in interface outside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
aaa authentication ssh console LOCAL
aaa authentication http console LOCAL
http server enable
http 192.168.250.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet timeout 5
ssh 192.168.250.0 255.255.255.0 inside
ssh timeout 5
ssh version 2
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
username mvadmin password 8Ry0koA9un5B4p74 encrypted
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:4bce0170a7e62e40c6bdbc458d647837
: end
Solved! Go to Solution.
03-04-2013 01:35 PM
Hi,
Is this ASA simply working between 2 private network ranges in the production network? Or does "outside" interface in the production enviroment actually have a public IP address range?
If we are talking about a firewall that simply handles LAN traffic between private network you could simply leave the NAT configuration blank. By default in softwares 8.3 and above you dont need any NAT configurations if you dont want to specifically NAT something to different IP address.
If your production firewall is below 8.3 (8.2 or below) then naturally the NAT operation is a bit different. In those softwares I think the "nat-control" setting defines if traffic requires NAT or not.
In your lab environement no "outside" host can access "inside" hosts with their original IP address (or any address for that matter) since youre doing PAT from "inside" to "outside". There should be some NAT0 type configuration to enable the 2 networks to directly communicate/initiate connection in both directions. Or as I mentioned you could remove all NAT configurations. (In that situation the "outside" network hosts would ofcourse need route for the "inside" network pointing towards the ASA "outside" interface)
Can you clarify the situation a bit?
- Jouni
03-05-2013 08:21 AM
Hi,
If you either go with
I personally would prefer the method of simply doing NONAT between the 2 networks.
You could still use the interface ACL to limit the traffic from "outside" to only allow the destination port UDP/54771 while blocking all other traffic.
I would personally use the ACLs so that I would only use ingress ACLs. In other words "access-group
Notice that you dont need more than one ACL per interface/direction. When the firewall has once allowed a connection there is no need to allow it anymore elsewhere. (On the eggress interface that is)
On the other hand if you specifically want to use NAT or its required from you and the decision is out of your hands then you could configure the following setup to both
You dont really need a Dynamic NAT if you only have one host on the "inside". You could simply use a single Static NAT statement for the said "inside" host. It would be both reachable and could reach the "outside" hosts.
The configuration format could be for example
8.2 and below software
static (inside,outside)
access-list OUTSIDE-IN remark Allow UDP/54771
access-list OUTSIDE-IN permit udp any host
access-group OUTSIDE-IN in interface outside
8.3 and above software
object network STATIC
host
nat (inside,outside) static
access-list OUTSIDE-IN remark Allow UDP/54771
access-list OUTSIDE-IN permit udp any object STATIC eq 54771
access-group OUTSIDE-IN in interface outside
access-list INSIDE-IN remark Allow all
access-list INSIDE-IN permit ip host
access-group INSIDE-IN in interface inside
Please rate/mark the question as answered if the information has been helpfull and has answered your question.
Naturally ask more if needed
- Jouni
03-04-2013 01:35 PM
Hi,
Is this ASA simply working between 2 private network ranges in the production network? Or does "outside" interface in the production enviroment actually have a public IP address range?
If we are talking about a firewall that simply handles LAN traffic between private network you could simply leave the NAT configuration blank. By default in softwares 8.3 and above you dont need any NAT configurations if you dont want to specifically NAT something to different IP address.
If your production firewall is below 8.3 (8.2 or below) then naturally the NAT operation is a bit different. In those softwares I think the "nat-control" setting defines if traffic requires NAT or not.
In your lab environement no "outside" host can access "inside" hosts with their original IP address (or any address for that matter) since youre doing PAT from "inside" to "outside". There should be some NAT0 type configuration to enable the 2 networks to directly communicate/initiate connection in both directions. Or as I mentioned you could remove all NAT configurations. (In that situation the "outside" network hosts would ofcourse need route for the "inside" network pointing towards the ASA "outside" interface)
Can you clarify the situation a bit?
- Jouni
03-04-2013 01:57 PM
Thanks Jouni. The outside network is a private network encompassing a few AP's and a set of wireless hosts whos only job is to talk to the inside server. In the production environment, outside is 192.168.8.0/21 and inside is 172.16.0.0/16, though the only inside hosts are the server and the inside interface of the firewall. The server's actually directly connected to the inside interface port.
As for the NAT tables, the production ASA 5520 is on ASA 7.0(6), so the NAT config looks entirely different. Here's the actual NAT configuration in production:
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
There is no 'nat-control' statement set in the running config.
Obviously it's still just a generic PAT setup. Technically the solution doesn't strictly require NAT, since the inside server is the only host that physically has access to the outside hosts from the inside. I didn't write the original configuration, so this whole process has been trying, attempting to identify the reasons for various configuration elements before I can troubleshoot.
03-04-2013 02:10 PM
Hi,
Do the "outside" hosts use the ASA5520 interface IP address as the default gateway?
I guess in this case you could simply use this NAT0 configuration
access-list NAT0 permit ip 172.16.0.0 255.255.0.0 192.168.8.0 255.255.248.0
nat (inside) 0 access-list NAT0
What the above would do is that NO NAT would be done between these 2 networks. Any host on either network/interface of the ASA could reach eachother in either direction with the original IP address. Naturally in this case as I said you would have to make sure that both networks had a default route towards the ASA or atleast a route that points the other network towards the ASA.
On a side note. You wont be able to ping a remote ASA interface. In other words host on "inside" cant ping "outside" interface IP address. Hosts on "outside" can never ping "inside" interface IP address. This is just how the Cisco firewalls work.
If you want to try the NAT0 configuration on the ASA running 8.3
You can either
object network INSIDE
subnet 172.16.0.0 255.255.0.0
object network OUTSIDE
subnet 192.168.8.0 255.255.248.0
nat (inside,outside) source static INSIDE INSIDE destination static OUTSIDE OUTSIDE
The above will basically do the same as the configuration I mentioned earlier. This is just for the new softwares NAT configuration format. Does include alot more configurations
Maybe you can test the above things
Lets us know if it helps
- Jouni
03-05-2013 08:05 AM
Awesome, Jouni, that works on the lab ASA.
One last question. For this customer, running a NAT0 will work, but this config might not meet security requirements for other customers we have going forward with this same solution. Is there any way to use NAT to mask the inside local address space to the outside for outbound traffic (so outside devices receive packets from the firewall's outside interface as the source), and use some form of destination forwarding on outside-to-inside traffic that would allow us to address the layer 3 destination from outside to the firewall's outside interface, and have the firewall translate that destination to the server's specific inside local address? Could I do something like (and this may be a bit redundant, but I'm not sure where the NAT would take place, so I put both destinations on the ACL for both interfaces):
access-list 101 extended permit udp 192.168.8.0 255.255.248.0 host 192.168.10.20 eq 54771
access-list 101 extended permit udp 192.168.8.0 255.255.248.0 host 172.16.1.10 eq 54771
access-list 102 extended permit udp 192.168.8.0 255.255.248.0 host 192.168.10.20 eq 54771
access-list 102 extended permit udp 192.168.8.0 255.255.248.0 host 172.16.1.10 eq 54771
access-group 101 in interface outside
access-group 102 out interface inside
global (outside) 1 interface
nat (inside) 1 172.16.0.0 255.255.0.0
static (outside,inside) 192.168.10.20 172.16.1.10 netmask 255.255.255.255
And then address my unicasts from outside to the outside interface of the firewall (in this example, 192.168.10.20)?
Would that source-translate all inside-to-outside traffic to have the inside global of the outside interface, and then destination-translate all outside-to-inside traffic destined for the outside interface to the local server IP, and allow only the UDP unicasts on 54771 through? Or would I still run into the same problem with the NAT translation?
03-05-2013 08:21 AM
Hi,
If you either go with
I personally would prefer the method of simply doing NONAT between the 2 networks.
You could still use the interface ACL to limit the traffic from "outside" to only allow the destination port UDP/54771 while blocking all other traffic.
I would personally use the ACLs so that I would only use ingress ACLs. In other words "access-group
Notice that you dont need more than one ACL per interface/direction. When the firewall has once allowed a connection there is no need to allow it anymore elsewhere. (On the eggress interface that is)
On the other hand if you specifically want to use NAT or its required from you and the decision is out of your hands then you could configure the following setup to both
You dont really need a Dynamic NAT if you only have one host on the "inside". You could simply use a single Static NAT statement for the said "inside" host. It would be both reachable and could reach the "outside" hosts.
The configuration format could be for example
8.2 and below software
static (inside,outside)
access-list OUTSIDE-IN remark Allow UDP/54771
access-list OUTSIDE-IN permit udp any host
access-group OUTSIDE-IN in interface outside
8.3 and above software
object network STATIC
host
nat (inside,outside) static
access-list OUTSIDE-IN remark Allow UDP/54771
access-list OUTSIDE-IN permit udp any object STATIC eq 54771
access-group OUTSIDE-IN in interface outside
access-list INSIDE-IN remark Allow all
access-list INSIDE-IN permit ip host
access-group INSIDE-IN in interface inside
Please rate/mark the question as answered if the information has been helpfull and has answered your question.
Naturally ask more if needed
- Jouni
03-05-2013 10:02 AM
Perfect, Jouni, thanks!
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