Home / server / Questions / 743108
Accepted
Steffen Müller
Asked: 2015-12-16 02:22:00 +0800 CST

How to allow UDP broadcast between interfaces on a Cisco ASA 5506-X

  • 772

I have a CISCO ASA 5506-X with 4 configured interfaces and a set of access-lists etc. It is configured via CLI and is running in routed mode, not transparent. Everything is running well, but now I have a problem I could not yet solve:

One of the interfaces contains a subnet (192.168.2.*) with devices that send out a UDP broadcast to discover another kind of devices. Those other devices are in another subnet in another interface (192.168.3.*). The udp broadcast is global (255.255.255.255) on a certain port.

I want the global UDP broadcast sent out in 192.168.2.* to also be sent to 192.168.3.* - and to allow the way back as well, of course.

On other Cisco devices, I already found out that one can do that with ip helper-address and ip forward-protocol commands - but the ASA models do not support those, as far as I can see.

So, how do I get the global UDP broadcast across the interfaces?

firewall

3 Answers

  1. Best Answer

    I think the issues here is that you misunderstand what 255.255.255.255 means. Its not a "global Broadcast". The definition from the RFC (https://www.rfc-editor.org/rfc/rfc919):

    "The address 255.255.255.255 denotes a broadcast on a local hardware network, which must not be forwarded. This address may be used, for example, by hosts that do not know their network number and are asking some server for it. Thus, a host on net 36, for example, may:

    • broadcast to all of its immediate neighbors by using 255.255.255.255
    • broadcast to all of net 36 by using 36.255.255.255

    In your case a host 192.168.3.0/24 sending a broadcast to 255.255.255.255 is saying is please send this to all hosts in 192.168.3.0/24. This is the same as sending a packet to 192.168.3.255. If a host in .3 wants to send a broadcast to .2 it needs to send a packet to 192.168.2.255. Having broadcasts from .3 rebroadcasted into .2 is essentially saying you want to make them the same subnet whilst keeping them as different subnets. (the common other name for a subnet is a "broadcast domain")

    What the ip helper and ip forward-protocol and the ASAs dhcprelay commands do is to capture the broadcast packet and forward it as a unicast packet to a specific host. normally a remote DHCP server but there are other uses. This is explicitly stated in first paragraph of the Checkpoint doc linked in the previous answer. It could be thought of as a kind of NAT. ie the destination address (255.255.255.255) is changed to a specified unicast IP, 192.168.3.10. and then routed as a normal unicast packet. This works great for DHCP and allows the DHCP server to be in a remote network and still receive and respond to DHCP requests but unfortunately even if the ASA supported the ip helper and ip forward-protocol commands it still couldn't solve your problem. What your asking violates the RFC and the definition of what a subnet is.

    The easiest solution here is to merge the 2 subnets into 192.168.2.0/23 then bridge the 2 interfaces and use the ASA in transparent mode to filter traffic between the 2 sets of hosts.

    If you can't do that that then you need to work out a more scalable way for your devices to find each other. Either sending broadcasts to their subnets respective broadcast addresses (192.168.3.255 and 192.168.2.255) or using some other Discovery method. 255.255.255.255 isn't a scalable or flexible solution.

    • 3

  2. There is no feature for this in the current version (probably for security reasons). Cisco implemented "dhcprelay" instead and didn't provide a means for more general broadcast forwarding.

    I'd suggest adding another device outside the ASA FW that could perform the same role (A Cisco router or a Linux machine perhaps). You will need to allow "directed broadcast" through the ASA.

    You might also consider using a different firewall platform which does support broadcast relay, for example a Checkpoint Firewall.

    Look here to see how its configured

    • 2

  3. I know I'm late to the party on this, but I couldn't find an acceptable answer to the question elsewhere. I recently solved this for the SSDP implementation that Sonos uses. It does leave a couple of ports open between the networks, but I was able to use a nat rule to blackhole the rest.

    The Sonos controllers send a UDP multicast message to 239.255.255.250:1900 to discover Sonos devices. The Sonos devices reply to the message. Then the controller issues http requests on port 1400/tcp to the devices to issue commands. The devices send http notifies directly to the controller on port 3400/tcp.

    You'll need to customize to your specific situation, so your mileage may vary.

    -solder000

    The Configuration:

    Enable multicast routing

    multicast-routing

    Interface References

    interface GigabitEthernet1/1
 nameif wan
 security-level 0
 no pim     

# sonos are here
interface GigabitEthernet1/2
 nameif insecure_lan 
 security-level 33

# rest of net here
interface GigabitEthernet1/8
 nameif secure_lan
 security-level 100

    Various Objects Used by the rules

    # network objects
object network net_secure
 subnet 192.168.2.0 255.255.255.0
object network net_insecure
 subnet 192.168.20.0 255.255.255.0

# blackhole ip, this should be an unused IP
object network obj_secure_blackhole
 host 192.168.2.7

# SSDP related objects
object service SSDP
 service udp destination range 1900 1901 
 description Simple Service Discovery Protocol
object service bidir-ephemeral
 service udp source range 32768 65535 destination range 32768 65535 
 description bidir ephemeral port range
object network obj_ssdp
 host 239.255.255.250
object network net_multicast
 range 224.0.0.0 239.255.255.255

# sonos service objects
object service sonos-3400-tcp
 service tcp destination range 3400 3401
 description Sonos App Control TCP/3400-3401
object-group service sonos-control
 service-object object sonos-3400-tcp 
 service-object object bidir-ephemeral

# sonos network objects
object network obj_sonos_arc
 host 192.168.20.131
 description Sonos Arc
object network obj_sonos_move
 host 192.168.20.199
 description Sonos Move
object-group network sonos
 network-object object obj_sonos_arc
 network-object object obj_sonos_move

    ACLs (order matters)

    # interface group definitions
access-group insecure_lan_access_in in interface insecure_lan
access-group secure_lan_access_in in interface secure_lan


# allow Sonos devices to communicate back to secure networks
access-list insecure_lan_access_in extended deny ip object-group sonos object obj_secure_blackhole

access-list insecure_lan_access_in extended permit object-group sonos-control object-group sonos object net_secure 

# block the rest of the traffic from insecure to secure
access-list insecure_lan_access_in extended deny ip any object net_secure

# block insecure multicast traffic
access-list insecure_lan_access_in extended deny ip any object net_multicast 


# allow ssdp traffic in from the secure net
access-list secure_lan_access_in extended permit object SSDP any object obj_ssdp 

# block the rest of the multicast nets
access-list secure_lan_access_in extended deny ip any object net_multicast

    Multicast route

    # route the multicast outbound from secure to insecure
mroute 192.168.2.0 255.255.255.0 secure_lan dense insecure_lan

    NATs

    # secure lan dynamic nat'd to insecure (allows multicast to function correctly)
# this can be limited to just the SSDP service, if desired
nat (secure_lan,insecure_lan) source dynamic any interface

# allow sonos devices on insecure network to send to port 3400 on secure network
nat (insecure_lan,secure_lan) source static sonos sonos destination static 
net_secure net_secure service sonos-3400-tcp sonos-3400-tcp no-proxy-arp

# any other traffic that the sonos might send to secure network is sent to the blackhole
nat (insecure_lan,secure_lan) source static sonos sonos destination static net_secure obj_secure_blackhole unidirectional no-proxy-arp
    • 2