• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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.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
    naxnax
    last edited by Jan 10, 2013, 2:48 PM

    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 Jan 11, 2013, 11:57 AM

      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 Jan 20, 2013, 8:18 PM

        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 Jan 21, 2013, 9:49 PM

          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.
            [[user:consent.lead]]
            [[user:consent.not_received]]