Subnet directed broadcast through vpn tunnel

valerio_vanni
valerio_vanni Posts: 91  Ally Member
First Answer First Comment Friend Collector Second Anniversary
Setup is: a local network, with a firewall (USG-Flex), and a client connected with ipsec vpn tunnel. Or 2 local networks, connected with ipsec vpn tunnel.
Result is the same, the common thing is that there is a tunnel between sender and receiver.
Policy control is "allow and log" in both direction.

A packet is directed at the broadcast address of the remote network, and it doesn't reach its destination. It's a wake on lan broadcast call, that works inside the single network.

The only thing I see in logs is that the package reaches receiver firewall (and it's accepted).
But nothing more.

All Replies

  • WJS
    WJS Posts: 155  Master Member
    5 Answers First Comment Friend Collector Second Anniversary
    1) Your purpose is to make VPN User can access internal network ?
    2) A packet is directed at the broadcast address of the remote network, and it doesn't reach its destination.
    ->Does the VPN User's NIC IP conflict with the firewall ? 
    3) can you share the brief topology and hint IP address  here ?
  • valerio_vanni
    valerio_vanni Posts: 91  Ally Member
    First Answer First Comment Friend Collector Second Anniversary
    edited January 2022
    WJS said:
    1) Your purpose is to make VPN User can access internal network ?
    2) A packet is directed at the broadcast address of the remote network, and it doesn't reach its destination.
    ->Does the VPN User's NIC IP conflict with the firewall ? 
    3) can you share the brief topology and hint IP address  here ?
    1) Yes, they already can. Normal traffic from IP to IP is working fine. Ping, rdp, smb etc.
    The issue is on broadcast traffic, when a client tries to wake up a client on the remote network sending packets to remote broadcast address.
    Software used is mc-wol: https://www.matcode.com/wol.htm

    command is:
    mc-wol.exe 80:6d:97:0a:f4:d6 /a 10.10.40.255

    2) No, it doesn't

    3) We have a remote client, with Zyxel Ipsec client, variable local address and fixed assigned (locally, inside ipsec client) 192.168.5.*.
    On the other side, behind a USG Flex, there is a LAN with addresses 10.10.40.0/24. Firewall has LAN address 10.10.40.254.

    In USG Flex log, I see that packet is received and is accepted by firewall rule.

    priority:14, from IPSec_VPN to ZyWALL, UDP, service others, ACCEPT 192.168.5.86:3813    10.10.40.255:65535

    But here I see something that seems not to be OK: IPSec_VPN to ZyWALL.
    Why "to zywall"? it should be classified as "IPSec_VPN_to_LAN1". A packet with .255 should be broadcasted on local network, not to the device itself.

  • WJS
    WJS Posts: 155  Master Member
    5 Answers First Comment Friend Collector Second Anniversary
    In my option, It's hard to implement on Zyxel Firewall. Layer3 device always split "Broadcast Domain" except for some router support "Directed-Broadcast".
    without the feature.It will casue Magic Packet cannot through LAN interface.

  • valerio_vanni
    valerio_vanni Posts: 91  Ally Member
    First Answer First Comment Friend Collector Second Anniversary
    This would be directed broadcast, directed to remote subnet.

    My aim is not to have a single broadcast domain, with firewall that detects local broadcast and forward to remote.
    I send broadcast to remote subnet.255, and I expect it to be broadcasted.
    Instead, it's received by firewall. ACCEPT... but accept to do what?


  • WJS
    WJS Posts: 155  Master Member
    5 Answers First Comment Friend Collector Second Anniversary
    edited January 2022
    Yes ,Log accept ,but the fw didn't forward broadcast  to  the local lan(10.10.40.x).

    In your topology ,The client send the broadcast packet dst:10.10.40.255,MAC:ff:ff:ff:ff:ff:ff. The payload contain remote host's MAC.

    Here are the behaviors about Layer 3 receive Broadcast. You can find out in RFC919.
    https://datatracker.ietf.org/doc/html/rfc919

    Of course, turning on some functions (like Directed-Broadcast in Cisco ) can achieve the purpose, but it seems that fw does not support

  • valerio_vanni
    valerio_vanni Posts: 91  Ally Member
    First Answer First Comment Friend Collector Second Anniversary
    edited January 2022
    Now it's clear why the packet is considered "to zywall". "Again, the gateway should consider itself a destination of the datagram".

    About not broadcasting, is this a recent strip down from firmware?

    I remember that many years ago it was working with Zyxel firewalls: remote users connected to vpn, launched a local batch file with a command like that I wrote before, their PC at the office waked up and then they could rdp into it.

    And I remember it worked out of the box, there wasn't anything to enable.


Security Highlight