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

    Multiple subnets on one interface (hetzner public IP block)

    Scheduled Pinned Locked Moved Routing and Multi WAN
    9 Posts 4 Posters 3.5k 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.
    • N
      noratx
      last edited by

      Hi!

      I got two /29 subnets, where of one is currently setup and working.
      x.x.239.144/29 (setup and working)
      x.x.163.16/29 (new subnet)

      My LAN interface has the IP x.x.239.145
      How do I set up so that any other machines behind LAN interface can use the x.x.163.16 subnet?

      Or do I need to add another interface?

      Current setup is one root server with VMWare ESXi, where pfsense is used to route my IP's.

      1 Reply Last reply Reply Quote 0
      • N
        noratx
        last edited by

        I have almost managed to configure it.. but I seem to miss something and I do not know what…

        I had to add another vswitch in vmWare and added a new network card.
        I now have LAN, WAN and SECLAN interfaces.
        I installed a new guest VM and connected it to the SECLAN interface.
        It does connect to the internet, however, the VM does not seem to be reachable from outside the Hetzner network.

        Inside the Hetzner Network, I can access over both http and ssh.
        But as soon as I try from my home PC, I am being blocked.

        I have set up the following rules/NAT's:

        NAT:
        Manual Outbound NAT
        Interface -> WAN
        Source -> x.x.163.16/29
        Source port -> *
        Destination -> *
        Destination port -> *
        NAT Address -> WAN address
        NAT port -> *
        Static port -> Randomize source port

        Rules:
        WAN -> Allow IPv4 TCP from any source and port to x.x.163.18 on port 80 using any GW
        WAN -> Allow IPv4 TCP from any source and port to x.x.163.18 on port 22 using any GW
        SECLAN -> Allow any protocol from any source to any destination

        Once I get it to work, I will restrict it a bit more and change the ports..
        But at this moment, I can not for the love of my life figure out why I can not connect to the VM from my home computer, but I can from within the Hetzner network...

        1 Reply Last reply Reply Quote 0
        • N
          noratx
          last edited by

          Anyone at all who can help me shed some light over the situation?

          1 Reply Last reply Reply Quote 0
          • N
            noratx
            last edited by

            I have tried to do a packet capture, and it seems that trafick is flowing to the WAN interface atleast.
            According to my FW rules, it should be allowed to pass.
            So question is now, could it be a routing problem?
            How do I make sure that PFSense is routing packets with destination xxx.xxx.163.18 to the SECLAN interface?)
            Do I need to add a static route or something?

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by

              I can understand wanting to obfuscate pubic IP.. But giving the host part of the address makes it really hard to follow what your wanting to do exactly..

              Are they even public?  If so why are you messing with outbound natting?

              Here is the thing, pfsense just like any router - that has networks attached to it - knows how to get to those networks.  You do not have to create any sort of static routes.  But if you want say opt1 network to talk to opt2 network then your going to have to create firewall rules.  And if these are actually public IPs - then your going to want to disable natting.

              The lan interface out of the box will have any any rules, but when you create opt interfaces there be no rules. So you have to create the rules you want on those new interfaces.

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • C
                CC
                last edited by

                I think he means there's 2 blocks being passed down the 1 interface, the question is is the ISP routing the 163.16/29 to the WAN address you are using or are they just expecting you to proxy arp for it?

                Can we have the WAN and the LAN interface configurations please?

                1 Reply Last reply Reply Quote 0
                • N
                  noratx
                  last edited by

                  Hi!

                  Thank you very much johnpoz and CC for replying.

                  CC is right, the ISP are routing both 239.144/29 and 163.16/29 to the WAN address (78.xxx.xxx.121)

                  I am not exactly sure which configs of the WAN and LAN interface you are asking for. But I will write what I think you might be looking for.
                  If I missed anything, please do specify.

                  Current setup of PFSense is the following:

                  Interfaces:
                  WAN - 78.xxx.xxx.121 (virtual IP xxx.xxx.239.148)
                  LAN - xxx.xxx.239.145
                  NATLAN - xxx.xxx.239.148
                  SECLAN - xxx.xxx.163.17

                  The VM's on the LAN interface are NAT'ed with one-to many I suppose.
                  They accessible through 239.146, 239.147, 239.149, 239.150, but when using a service like whatismyip.org, they are seen as 78.xxx.xxx.121.
                  (At a later time, I would like to reconfigure this to that each machine are both accessible and seen with it's own IP. Is this 1:1 NAT?)

                  The NATLAN interface is for testing purpouses and are port forwarded.
                  VM's connected to this interface are on a private 192.168 network (and all are working as it should).

                  It's, as I said, the SECLAN that does not work properly.

                  Port Forward Rules:
                  Interface -> WAN Protocol -> TCP Source Address -> * Source Ports -> * Dest Address -> xxx.xxx.239.148 dest ports -> 3389 NAT IP -> 192.168.0.2 NAT Ports -> 3389 Description -> Win_Dev1_RDP
                  Interface -> WAN Protocol -> TCP Source Address -> * Source Ports -> * Dest Address -> xxx.xxx.239.148 dest ports -> 89 NAT IP -> 192.168.0.2 NAT Ports -> 80 Description -> Win_Dev1_HTTP
                  Interface -> WAN Protocol -> TCP Source Address -> * Source Ports -> * Dest Address -> xxx.xxx.239.148 dest ports -> 3390 NAT IP -> 192.168.0.3 NAT Ports -> 3389 Description -> Win_Dev2_RDP
                  Interface -> WAN Protocol -> TCP Source Address -> * Source Ports -> * Dest Address -> xxx.xxx.239.148 dest ports -> 90 NAT IP -> 192.168.0.3 NAT Ports -> 80 Description -> Win_Dev2_HTTP

                  NAT outbound rules:

                  General logging options:
                  Manual Outbound NAT rule generation

                  Mappings:
                  Interface -> WAN Source -> 192.168.0.0/24 Source port -> * Destination -> * Destination port -> * NAT Address -> xxx.xxx.239.148 -> * Static port -> Randomize source port

                  Interface -> WAN Source -> 127.0.0.1/8 Source port -> * Destination -> * Destination port -> * NAT Address -> WAN address NAT port -> * Static port -> Randomize source port
                  Interface -> WAN Source -> 127.0.0.1/8 Source port -> * Destination -> * Destination port -> 500 NAT Address -> WAN address NAT port -> * Static port -> Keep source port static

                  Interface -> WAN Source -> xxx.xxx.239.144/29 Source port -> * Destination -> * Destination port -> * NAT Address -> WAN address NAT port -> * Static port -> Randomize source port
                  Interface -> WAN Source -> xxx.xxx.239.144/29 Source port -> * Destination -> * Destination port -> 500 NAT Address -> WAN address NAT port -> * Static port -> Keep source port static
                  Interface -> WAN Source -> xxx.xxx.163.16/29 Source port -> * Destination -> * Destination port -> * NAT Address -> WAN address NAT port -> * Static port -> Randomize source port
                  Interface -> WAN Source -> xxx.xxx.163.16/29 Source port -> * Destination -> * Destination port -> 500 NAT Address -> WAN address NAT port -> * Static port -> Keep source port static

                  Firewall rules:
                  LAN, NATLAN, SECLAN all packets are allowed to pass.

                  Filtering is done on WAN
                  Currently, until I get things to work, all traffic on all protocols from any source are allowed to pass from WAN to network xxx.xxx.163.16/29 using any port.

                  1 Reply Last reply Reply Quote 0
                  • jahonixJ
                    jahonix
                    last edited by

                    @johnpoz:

                    I can understand wanting to obfuscate pubic IP.. But giving the host part of the address makes it really hard to follow what your wanting to do exactly..

                    That's what RFC5737 addresses (Test-Net) are for:

                    192.0.2.0/24 (TEST-NET-1)
                    198.51.100.0/24 (TEST-NET-2), and
                    203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.

                    Think of the IPv4 equivalent for example.com and example.org
                    Those IPs are on the bogon list and not publicly routed.

                    1 Reply Last reply Reply Quote 0
                    • N
                      noratx
                      last edited by

                      I finally found the problem…

                      There was never any problems with my config.
                      My ISP had routed the subnet through the wrong gateway!

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