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

    Simple Nat with multiple IP's not working with TekSavvy

    Scheduled Pinned Locked Moved NAT
    4 Posts 3 Posters 2.6k 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
      naxnax
      last edited by

      Hey all,

      I've been stuck on this for a couple of days so I figured I'd finally ask for help… ;)

      I have a static IP along with an additional (different) /29 subnet from TekSavvy.

      I have a pfSense machine in bridge mode with the Bell router that TekSavvy provided.  The pfSense machine is using the main static IP.  Everything seems to work perfectly, I have incredible up/down speeds on my lan so all is good in that regard.

      On the pfSense machine I've attached my subnet of virtual IP's in the Virtual IP section (in ARP).  Used 1:1 Nat to attach static IP's to internal local servers and added firewall rules to allow for HTTP traffic from wan to lan (figured I would test with a simple web server).

      Sadly I can't seem to be able to reach my internal machines.  PfSense logs don't show any traffic being blocked.  I tried an external trace route and it seems to end at an IP that's not my router IP (a similar ip on TekSavvy network but not my ip).  This may simply mean that all other trace info is denied once it reaches TekSavvy or that my static IP's are improperly routed.

      Anyway, TekSavvy allows for this setup but does not support it so I'm not sure what to do.

      Any ideas?  Am I missing something?  How would I test if the pfsense box is the issue or if the traffic is incorrectly routed?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • P
        podilarius
        last edited by

        In diagnostics there is a packet capture. I would start that up on the WAN and then try to access your VIP from an external source. If you see packets getting to the WAN but nothing happening, then you are routed properly but have a config issue on the FW. If the packets never get to the WAN, then they are not routed properly
        Does TekSavvy route the IP to the your WAN address or the router in front of your WAN? By default ICMP is blocked on WAN, so you might want a rule in place while you troubleshoot this. That way you can be sure that it is not getting to you via traceroute.

        1 Reply Last reply Reply Quote 0
        • T
          tillburn
          last edited by

          I also have a /29 public IP pool. I'll IP's referenced are truncated for security and simplicity.

          I am using .105 as the router IP, trying to establish 106 and 107 as virtual IP's using this semi applicable walk through : http://blog.stefcho.eu/?p=455

          Our situation is so similar, hopefully we can get this figured out and we both win.

          Here's my setup so we can compare notes.

          Docsis3 cable modem –---> gateway .110
          Router .105/29----> Lan 192.168.1.x (squid and snort active)
          DHCP configured on Lan for 100-149
          Virtual machine .150 (needs 1to1 to .107)
          2 CARP address configured Public .106 and .107 (default CARP settings)
          1to1 settings:

          Disabled   unticked
          Interface    WAN
          External subnet IP  .107
          Internal IP  single host .150 (not unticked)
          Destination type=any (not unticked)
          description 1071to1
          NAT reflection disabled

          I basically followed that guide linked above. The picture references are of a different GUI version but by process of elimination one can follow along. I'll trouble shoot as mentioned in the reply and report back.

          As of right now:
          I've got nothing hitting the lan address of .150 from the virtual IP of .107, starting the trouble shooting now.

          Regards,

          Till

          1 Reply Last reply Reply Quote 0
          • P
            podilarius
            last edited by

            I have to assume that you have a WAN rules to poke the necessary port openings as holes in the firewall? Those rules are pointing to .150 on the LAN.
            Are you monitoring tcpdump on the firewall to make sure they are getting to the firewall? That would be where I start.

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