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

    Packets coming and going back to the WAN interface

    Scheduled Pinned Locked Moved Routing and Multi WAN
    5 Posts 2 Posters 4.7k 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.
    • J
      jullima
      last edited by

      Hello Everybody,

      I have a little problem with pfSense installed on my Alix board (http://www.pcengines.ch/alix2d3.htm). I have a standard user broadband Internet connection. My goal with pfSense is just to setup a VPN for my PS3 (for Netflix Service, and it is working) and also to monitor/filter the traffic on my NAS (Qnap).

      All my computers, NAS and other devices (except my PS3 that is connected on the LAN interface of pfSense) are connected with on the same subnet behind my ISP router. I connected the WAN port of the pfSense firewall on the LAN Subnet of my ISP router. Then I configured the default gateway on pfSense with the LAN IP of my ISP router. From pfSense itself and its LAN interface, Internet is working correctly.

      But on the WAN side of pfSense, I configured the default gateway with the WAN IP of pfSense. I want that the traffic leave my computer (or other device as iPhone, etc…) go to pfSense (default gateway of end devices) then pfSense do his firewall job and after redirect the traffic to my ISP router. I know that after, the return traffic wil bypass pfSense because the IPS router will send the traffic directly to the end device.
      But it does not work, I do not have any connectivity. I did a test (ping google) with tcpdump running on the WAN interface of pfSense, and I only see the ICMP request coming from my computer. pfSense does not send back the IP Packets its default gateway.
      I already tried to check the "Bypass firewall rules for traffic on the same interface" box without any success. Do you have any idea how to solve this issue ?

      Thank you very much for your support.

      Julian

      Why I want to do this setup :

      I need Wifi and wired on the same subnet in order to use correctly the DLNA service (between my TV and my NAS). If I want to do this on the LAN interface of pfSense, I have to invest into a switch and an access-point. And I do not want to spend this money now.

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        I did this once, in a place where I wanted to use the WiFi that was already on the front-end ADSL device.

        1. First, you will need a firewall rule on pfSense WAN to allow traffic coming in from WANnet which is your "ISP LAN" (you can block incoming from the ISP router LAN IP, then allow the rest of the subnet - that way if anyone sets up a port forward on the ISP router to your pfSense WAN IP, it will be blocked).
        2. Turn off DHCP on ISP router, give pfSense WAN a static IP in that subnet and turn on DHCP - clients will get pfSense WAN IP as their gateway and DNS.
        3. Turn on manual outbound NAT, add a rule to NAT from WANnet to WANaddress - then packets arriving from clients on the WAN side will be NAT'd out to the ISP router, thus the ISP router sees a source IP of pfSense WAN IP. When response packets come back, ISP router will send them to pfSense WAN IP, and pfSense will "unNAT" them and deliver them to the correct clients on the pfSense WAN side. Without this, pfSense sees no returning traffic and after some time kills the state(s).
          This makes the pfSense WAN side network function just like the LAN side - clients get DHCP and DNS service from pfSense, and client connections are NATed out to the front-end router.
          The traffic is all NAted again a second time by the ISP router - but that is happening for your pfSense LAN anyway.

        Note: You can also set a "sloppy states" option somewhere to make pfSense ignore the unbalanced traffic flow. My solution above balances the traffic flow so pfSense packet filter will operate normally.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • J
          jullima
          last edited by

          Hi Phil,

          Thank you for your answer. I did the configuration that you mentioned (except that I configured a static IP adress in order to test first) and unfortunately it does not work.

          I taked some logs and what I can see, is that the NAT is not working correctly because in the state table, the source IP is still the computer and not the pfSense.

          [2.1-RELEASE][admin@viking.home.net]/root(63): pfctl -s nat
          no nat proto carp all
          nat-anchor "natearly/" all
          nat-anchor "natrules/          " all
          nat on vr1 inet from 192.168.101.0/24 to any port = isakmp -> 192.168.100.2 static-port
          nat on vr1 inet from 192.168.101.0/24 to any -> 192.168.100.2 port 1024:65535
          nat on vr1 inet from 127.0.0.0/8 to any -> 192.168.100.2 port 1024:65535
          nat on ovpnc1 inet from 192.168.101.0/24 to any port = isakmp -> 10.200.1.50 static-port
          nat on ovpnc1 inet from 192.168.101.0/24 to any -> 10.200.1.50 port 1024:65535
          nat on ovpnc1 inet from 127.0.0.0/8 to any -> 10.200.1.50 port 1024:65535
          nat on vr1 inet from 192.168.100.0/24 to any -> 192.168.100.2 port 1024:65535

          The source address ist 192.168.100.50 (on the same subnet as the WAN interface of pfSense). I can see that I have some matches :

          [2.1-RELEASE][admin@viking.home.net]/root(62): pfctl -vs nat
          ….
          nat on ovpnc1 inet from 127.0.0.0/8 to any -> 10.200.1.50 port 1024:65535
            [ Evaluations: 0        Packets: 0        Bytes: 0          States: 0    ]
            [ Inserted: uid 0 pid 34733 ]
          nat on vr1 inet from 192.168.100.0/24 to any -> 192.168.100.2 port 1024:65535
            [ Evaluations: 46        Packets: 64        Bytes: 5890        States: 0    ]
            [ Inserted: uid 0 pid 34733 ]
          no rdr proto carp all
          …

          But when I check the state table, I see the connection with the original IP

          [2.1-RELEASE][admin@viking.home.net]/root(66): pfctl -ss
          …
          vr1 tcp 173.194.116.95:443 <- 192.168.100.50:60981      CLOSED:SYN_SENT
          vr1 tcp 173.194.116.76:443 <- 192.168.100.50:60982      CLOSED:SYN_SENT
          vr1 tcp 193.247.166.11:80 <- 192.168.100.50:60983      CLOSED:SYN_SENT
          vr1 tcp 193.222.86.84:443 <- 192.168.100.50:60984      CLOSED:SYN_SENT

          Do you know why it is like that ?

          Thank you in advance.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            I think the states list in pf will still show the real source and destination IPs. I was just setting up a pfSense box for another office, and doing it behind my home LAN. So I made my home LAN route through the pfSense by:
            ADSL router home LAN IP 10.49.175.250/24 - with DHCP disabled
            pfSense WAN IP - 10.49.175.1/24 static, gateway 10.49.175.250, giving out DHCP 10.49.175.32 to 63. pfSense WAN is sitting on home LAN.

            1. Add rule on pfSense WAN to allow source WANnet, destination any
            2. Turn off DHCP on my ADSL router
            3. Turn on DHCP on pfSense WAN
            4. Add manual outbound NAT rule from the WAN subnet to WAN address (1st attachment)
            5. Release/renew the IP on my laptop, it got 10.49.175.32 with gateway and DNS server 10.49.175.1 (pfSense WAN) - good

            Now I traceroute to Google and it goes through pfSense WAN first, then the ADSL router:

            C:\Users\davp_000>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1     9 ms     9 ms     8 ms  10.49.175.1
  2    15 ms    13 ms    14 ms  10.49.175.250
  3    53 ms    54 ms    51 ms  1-adsl.ntc.net.np [49.244.136.1]
  4    53 ms    60 ms    52 ms  202.70.65.233
  5    60 ms    54 ms    61 ms  htd-but.ne40-x8.xgei1-1-0.ntc.net.np [202.70.93.189]
  6    60 ms    55 ms    63 ms  202.70.93.149
  7   171 ms   170 ms   169 ms  72.14.214.177
  8   168 ms   168 ms   167 ms  209.85.243.158
...

            and I am posting here using this config. Some sample states look like:

            pfctl -ss
vr1 tcp 157.56.98.108:443 <- 10.49.175.32:54324       ESTABLISHED:ESTABLISHED
vr1 tcp 10.49.175.32:54324 -> 10.49.175.1:14931 -> 157.56.98.108:443       ESTABLISHED:ESTABLISHED
vr1 tcp 108.160.163.35:80 <- 10.49.175.32:54326       ESTABLISHED:ESTABLISHED
vr1 tcp 10.49.175.32:54326 -> 10.49.175.1:61586 -> 108.160.163.35:80       ESTABLISHED:ESTABLISHED
vr1 tcp 176.223.198.114:80 <- 10.49.175.32:54333       ESTABLISHED:ESTABLISHED
vr1 tcp 10.49.175.32:54333 -> 10.49.175.1:21743 -> 176.223.198.114:80       ESTABLISHED:ESTABLISHED
vr1 tcp 176.223.198.114:80 <- 10.49.175.32:54334       ESTABLISHED:ESTABLISHED
vr1 tcp 10.49.175.32:54334 -> 10.49.175.1:27931 -> 176.223.198.114:80       ESTABLISHED:ESTABLISHED
vr1 tcp 157.55.133.145:12350 <- 10.49.175.32:54336       ESTABLISHED:ESTABLISHED
vr1 tcp 10.49.175.32:54336 -> 10.49.175.1:37439 -> 157.55.133.145:12350       ESTABLISHED:ESTABLISHED

            NAT-Outbound-Manual.png
            NAT-Outbound-Manual.png_thumb
            WANnet-rule.png
            WANnet-rule.png_thumb

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • J
              jullima
              last edited by

              Hello,

              Finally after my vacation I reinstalled from a new installation my pfsense and began to setup the NAT for the routing. And now it's working.  ;D

              Thank you for your support.

              Julian

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