NAT ACL Application

[Liamo]

Hello

I'm trying to understand if it will make any significant difference if ACL's are applied to the inside or outside NAT interface.

I have one device that I want to hang out in the breeze on a different private subnet, exposing it to the interwebs, to prove a point.
Namely some stupid IP TV box that no one will give me TCP port information on.

Because I only have access to one Cisco 1841 router and a Cisco switch, the plan was to create a couple of VLAN's, change (open) the current inside NAT subnet, pull the current ACL's off the edge dialer WAN interface and set them up on each internally NAT'ed VLAN's.
There will still need to be some basic ACL rules on the edge WAN interface to deny access to telnet and SSH, but are there any other reasons why shifting the ACL's from the NAT outside interface to the proposed two NAT inside interfaces wont work, or pose an unnecessary security risk?

Thank you
Liamo

[Richard Burts]

Liamo

The main issue is that if you move the access lists to inside interfaces that it exposes the router to access from outside. You need to be sure that the acl you do have on the outside interface protects each of the router interface addresses from any unwanted access. You also may need to change the acl to reflect the fact that address translation has already happened.

[Liamo]

Thank you for your reply Richard

The points you raise are the same concerns I have.
My WAN IP address is dynamic, so the present ACL's are fairly generic.
Deny, deny, deny, Allow specific DNS host. Allow specific NTP host. Allow HTTP established any.

It isn't an ideal scenario, granted. Hope I wont have to make the changes.
I may just revert to wire shark once the new IP TV box arrives and see what it is trying to do.

Regards

Liam

[Liamo]

Me again.
My ISP shipped out a new IPTV box which is referred to here in Australia as FetchTV.

Some activation issues aside, I have been looking at some Wireshark captures on my local ethernet network.
Turns out that this box is trying to make multicast requests per the following.
(1008 135.621481 10.97.16.251 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1)

My little 1841 router is not configured for multicast routing and I have an ACL deny ip 224.0.0.0 15.255.255.255 any rule inbound on the WAN interface.
I'm not particularly impressed because my Apple TV works fine unicast.

I have two options I guess, send the FetchTV box back to the ISP as a bin ornament or start playing around to allow multicast traffic in.
By default I understand that multicast routing is not configured.
I found an old Cisco 1800 ADSL router that I still have, so it may be a matter of setting up a DMZ after all and just hanging this FetchTV box out in the breeze.

I'm not particularly happy allowing multicast traffic through to everything else here at home.
I may have to do it to establish that the problem is in fact multicast routing.

All this work just to get Eurosport back. First world problems...

Thank you and regards Liam

[Richard Burts]

Liam

Thanks for the information. That multicast address is used by Simple Service Discovery Protocol which is associated with Universal Plug and Play (UPnP). This link has some information about its use

https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol

It is not clear to me whether the IPTV would use additional multicast addresses but as a first step you might think about doing a permit in your acl for that particular multicast address.

[Liamo]

Thanks again for your reply Richard.

I have nothing but time on my hands at the moment. Home with spinal injuries and no job.

I set up the second router that I had lying around, a Cisco 1801.
Shutdown the BRI and ATM interfaces and just use the FE port as the dialer WAN interface.
I mucked around with the two ACL lists on the dialer interface to no longer specifically deny all multicast address subnets.
No change.
Set up multicast routing and added the default VLAN interface to the PIM interface for multicast routing.
No change, but now counters on the inbound access list against the explicit deny all class A IP address subnets, to which VLAN 1 is part.
Finally set up IP Inspect on this 1801 and bingo. The IPTV STB is playing content. 
Wifey is very happy. Haha.

Interesting thing to me now is that using Wireshark, none of the multicast requests are coming from the IPTV STB itself.
The default gateway, VLAN 1 is the IP address that is showing the SSDP requests.

So, the Cisco 1801 and FetchTV STB are now in a separate subnet.
Its an either or situation. Watch TV or have internet.
Next task will be to reverse some of the changes on the 1801 until the IPTV stream falls over so I can better understand.

Then I will have to make a decision, run two routers, two subnets or be comfortable enough to allow the IPTV multicasting on my, lets say, internal Cisco 1841.
Its been a bit of a challenge for me, because I forgot a significant amount of this stuff, only being a telecoms tech for the last 12 years. Build it, test it, prove layer 1. Move on.

Thank you and regards

Liam

[Richard Burts]

Liam

Thanks for the update. Good luck figuring out how you want this to work.