Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Vr2 port doesn't have access to it's DHCP provider

    Scheduled Pinned Locked Moved Firewalling
    4 Posts 2 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T Offline
      torontob
      last edited by

      Hi Everyone,

      I have an Alix board with 3 ports on it. Vr0 is dedicated to LAN which  provides DHCP. Vr1 is the WAN which obtains public IP from ISP. Vr2 is also WAN which obtains IP from another 3Com router.

      I can see the interface on Vr2 is UP and it has obtained IP 192.168.10.70 and it's gateway is 192.168.10.1 but when I go to Diagnostic > Ping I get this:

      Ping output:
      PING 192.168.10.1 (192.168.10.1) from 192.168.10.70: 56 data bytes
      
      --- 192.168.10.1 ping statistics ---
      3 packets transmitted, 0 packets received, 100.0% packet loss
      

      Needless to say that computers on that network can't reach pfsense router which now has the IP address 192.168.10.73 and as you can see I can't even ping to those computers.

      In the Vr2 firewall I have the following:

      Proto	Source	Port	Destination	Port	Gateway	Schedule	Description	
        TCP	                *	 *	 *	 *	 *	  	                 Allow-All 
      

      What else am I missing? That rule should allow anything coming in. Or at least I shouldn't be blocked for pinging to the DHCP provider from Diagnostics > Ping section.

      Thanks for the input

      1 Reply Last reply Reply Quote 0
      • T Offline
        torontob
        last edited by

        NVM, problem was related to a spoofed MAC address that I picked for that interface (01:01:01:01:01:01) and the 3com router on the other end was smart to not allow any communication.

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG Offline
          GruensFroeschli
          last edited by

          If it were 00:01:01:01:01:01 it would probably have worked.
          The last bit of the first octet is the multicast-bit and should only be set in the destination, but never as source.

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • T Offline
            torontob
            last edited by

            Thanks. Good to know. Learning a new thing everyday.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.