topic Re: Routing in Network Security

Routing

l.pederson — Tue, 12 Mar 2019 01:09:35 GMT

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

Routing

Jouni Forss — Mon, 04 Mar 2013 21:35:11 GMT

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

Re: Routing

l.pederson — Mon, 04 Mar 2013 21:57:45 GMT

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.

Routing

Jouni Forss — Mon, 04 Mar 2013 22:10:40 GMT

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

Remove ALL NAT configurations
Or configure the following NAT (which will kind make the existing NAT useless anyway)

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

Re: Routing

l.pederson — Tue, 05 Mar 2013 16:05:21 GMT

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?

Re: Routing

Jouni Forss — Tue, 05 Mar 2013 16:21:28 GMT

Hi,

If you either go with

8.3 and later software: You could either leave the NAT out completely or use the configuration format/logic I mentioned above
8.2 and earlier software: You could either leve the NAT out completely (making use the "nat-control" setting is correctly setup) or use the configuration format/logica I mentioned earlier above

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 in interface "

On the "outside" interface you would be able to just allow the UDP/54771 destination port towards host on the "inside" host.
On the "inside" interface you could either allow all or perhaps limit the traffic to certain ports.

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

Mask the "inside" host towards the "outside" network
Make it possible for the "outside" hosts to connect to the "inside" host using the NAT IP address

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

ACLs use the NAT IP address as the destination IP address

static (inside,outside) netmask 255.255.255.255

access-list OUTSIDE-IN remark Allow UDP/54771

access-list OUTSIDE-IN permit udp any host eq 54771

access-group OUTSIDE-IN in interface outside

8.3 and above software

ACLs use the Real IP address as the destination IP address
Below example uses the actual "object" since it contains the Real IP address

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 any

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

Re: Routing

l.pederson — Tue, 05 Mar 2013 18:02:47 GMT

Perfect, Jouni, thanks!