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

problems with Virtual IP's and port forwarding

Scheduled Pinned Locked Moved NAT
4 Posts 4 Posters 590 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.
  • L
    linuxpc4me
    last edited by May 31, 2018, 6:37 PM

    hello All!

    Im flamboozled on using Virtual IP's and port forwarding. Here is an explanation of my system.

    If someone can see why I cannot access the server from outside I'd be very thankful.....

    framework of traffic flow:

    8 static public IP from suddenlink

    (example)
    208.180.145.111
    208.180.145.222
    208.180.145.333
    .444
    .555
    .666
    .777
    .888

    Using netgate sg4860 appliance
    208.180.145.111 is primary WAN

    LAN port is 192.168.2.1 /24 and Ipchicken shows 208.180.145.111 as IP

    I am using OPT1 for my server
    local address on OPT1 = 192.168.222.1 /24 ( to match 2nd public IP )

    The others are Virtual IP's
    Virtual IP's are constructed as:
    Type: IP Alias
    Interface: WAN
    Address type: single address /24

    Port Forward rules for the OPT1 server are:

    interface: WAN (also tried the VIP 208.180.145.222)
    Protocol: TCP (tried tcp/udp as well)
    Destination: WAN
    Destination Ports: other; 6660 TO 6669 (is chat server)
    Redirect target IP: 192.168.222.101 (IP of server chat software is on)
    Redirect target port: other 6660
    NAT reflection "use system default"
    Filter rule association: "add associated filter rule"

    I cannot connect to the chat server externally.
    Internally from the chat server I can ping anywhere and access web, but nothing gets in

    1 Reply Last reply Reply Quote 0
    • J
      johnpoz LAYER 8 Global Moderator
      last edited by May 31, 2018, 6:42 PM

      You need to make sure that the answer the server sends leaves via the vip.. If you forward say .100 to your box but the answer comes from your .200 IP on the wan interface then most clients would not work.

      Simple sniff would for starts show you the traffic gets to your wan interface on the vip. And then sniff on your opt to make sure pfsense sends it on and your server answers.

      Then validate where your answer is leaving your wan from the native IP or your vip.

      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
      • S
        SteveITS Galactic Empire
        last edited by Jun 4, 2018, 6:29 PM

        You need to make sure that the answer the server sends leaves via the vip

        This is done via Firewall/NAT/Outbound. Create a manual rule like:
        source: 192.168.222.101/32
        NAT address: 208.180.145.111

        Then the default rule for 192.168.222.0/24 with NAT address of "WAN address" is below that and will pick up all other PCs for the "normal" WAN IP.

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

        1 Reply Last reply Reply Quote 0
        • K
          KOM
          last edited by Jun 4, 2018, 6:41 PM

          https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

          1 Reply Last reply Reply Quote 0
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received