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

    Proxy ARP implementation

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    4 Posts 2 Posters 4.8k 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.
    • M
      mlimo
      last edited by

      Hi,

      I have been looking for a new firewall solution to replace my Shorewall setup (which has been great, but adding reporting etc is not as easy)

      My environment is as follows.

      LAN 192.168.0.0/24
      WAN PPPOE Static IP 165.xxx.xxx.xxx

      Additional IP's  203.35.xxx.xxx/29 (8) 203.36.xxx.xxx/28 (16)

      The IP's in the 203.35 range are either DNAT for specific ports or 1:1 to specific machines in my 192.168.0.0 network.
      All of these services are operating correctly.

      The catch is, I am running a virtual server configured with a live IP from the 203.36.xxx.xxx range.
      This configuration has been operating via Proxy ARP through my shorewall configuration.

      All my reading through the forums here would indicate that Proxy ARP is implemented or used or stated differently between the Shorewall and pfSense implementation.

      In the system log, the following log entry occurs.

      
      	kernel: arplookup 203.36.xxx.xxx failed: host is not on local network
      
      

      I have created a VIP for this address, but have not been able to get it transferred through to the 'LAN' interface for the Virtual appliance to operate and respond with.

      Is it actually possible to do this?

      I cannot reconfigure the virtual appliance.

      1 Reply Last reply Reply Quote 0
      • M
        mlimo
        last edited by

        Im judging by the lack of responses that my environment is not supported :(
        Oh well.

        I will definately by using pfSense for clients whose environments arent as complex as mine :)

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

          I'm not sure how your setup is exactly working.

          Are the additional IPs routed to your WAN?
          Are they all in use right now?
          Do you have the public IP directly on the server?

          There are several ways to go at such a problem.

          • Bridging
          • VIPs –> The public IP on the pfSense, the internal servers have private IPs, traffic from the public IP forwarded to the private IP.
          • routing

          You cannot use VIPs if you have the public IP directly on the server itself.

          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
          • M
            mlimo
            last edited by

            @GruensFroeschli:

            Are the additional IPs routed to your WAN?

            They are routed to my PPPoE address.  They are not configured on an adapter other than as virtual IP's.

            @GruensFroeschli:

            Are they all in use right now?

            The 8 IP Block is fully utilised via 1:1 NAT and are all working fine
            The 16 IP block is utilising 2 IP's at present.  1 is NAT, the other is configured as the live IP on the virtual linux system

            @GruensFroeschli:

            Do you have the public IP directly on the server?

            The only live IP configured is the PTP ip for my ADSL connection

            @GruensFroeschli:

            There are several ways to go at such a problem.

            • Bridging
            • VIPs –> The public IP on the pfSense, the internal servers have private IPs, traffic from the public IP forwarded to the private IP.
            • routing
              You cannot use VIPs if you have the public IP directly on the server itself.

            Presently, VIP's and routing are accomplishing things for all the other IP's.
            The IP that is causing the issue is the virtual machine configured with the real world ip (no internal IP address allocated)

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