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

    SNAT between LAN interfaces

    Scheduled Pinned Locked Moved NAT
    7 Posts 4 Posters 898 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.
    • S
      steveh_
      last edited by

      I'm trying to SNAT between 2 LAN interfaces (configured as seperate VLAN's)

      The device on VLAN2 that i'm trying to connect to is configured to only allow connections from it's local subnet.
      I'm trying to connect from a different subnet (VLAN1)

      I tried creating an outbound NAT rule with the source interface and network being the VLAN1 range.
      the destination network being VLAN2 range
      and the tranlation address being the interface address.
      This doesn't work.

      Testing the connection from test port works if i select the VLAN2 interface, so i know the device is responding.

      1 Reply Last reply Reply Quote 0
      • awebsterA
        awebster
        last edited by

        It sounds like you are on the right track, but you don't mention any firewall rules. You will need both a policy rule and a NAT rule.
        Add a policy rule on VLAN1 that will allow any device on VLAN1 to communicate with any device on VLAN2. You can adjust the rule later to lock it down.

        IPv4 * VLAN1_net * VLAN2_net *

        Next in order for the NAT rule to take effect, you need to either select Hybrid or Manual Outbound NAT generation, then create the following NAT rule.
        VLAN1 any * VLAN2_net * VLAN1_address *

        –A.

        1 Reply Last reply Reply Quote 0
        • S
          steveh_
          last edited by

          Hi awebster,

          Thanks for your reply.

          I already have firewall rules in place (I didn't mention this) as I can ping the device in VLAN2 from VLAN1. pfSense is in Manual Outbound NAT mode.

          Here is my NAT rule:

          9d7aae51-35a5-471d-a04f-568fe5baa148-image.png

          This doesn't seem to work.

          I should mention I have 2 firewalls with CARP interfaces setup, Running version 2.4.3-RELEASE

          There are a lot more VLANs setup, but to simplify i just mentioned the 2 VLANs i'm dealing with.

          Cheers

          1 Reply Last reply Reply Quote 0
          • chpalmerC
            chpalmer
            last edited by

            This post is deleted!
            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by johnpoz

              Which interface is CS... A source nat would be on the interface you want to nat to..

              So I have lan 192.168.9/24 (lan), and dmz 192.168.3/24

              So if I want traffic from 9 to look like it came from 3.253 (pfsense IP address in the dmz) I do this

              sourcenat.png

              So before I source nat if I sniff on the dmz interface and ping from the lan interface it looks like this

              21:18:50.528828 IP 192.168.9.100 > 192.168.3.32: ICMP echo request, id 1, seq 26162, length 40
              21:18:50.529127 IP 192.168.3.32 > 192.168.9.100: ICMP echo reply, id 1, seq 26162, length 40
              21:18:51.534524 IP 192.168.9.100 > 192.168.3.32: ICMP echo request, id 1, seq 26163, length 40
              21:18:51.534821 IP 192.168.3.32 > 192.168.9.100: ICMP echo reply, id 1, seq 26163, length 40
              21:18:52.539510 IP 192.168.9.100 > 192.168.3.32: ICMP echo request, id 1, seq 26164, length 40
              

              Now I enable that source nat, and then ping from 9.100 to 3.32 it looks like this

              21:21:06.222467 IP 192.168.3.253 > 192.168.3.32: ICMP echo request, id 64919, seq 26184, length 40
              21:21:06.222768 IP 192.168.3.32 > 192.168.3.253: ICMP echo reply, id 64919, seq 26184, length 40
              21:21:07.227626 IP 192.168.3.253 > 192.168.3.32: ICMP echo request, id 64919, seq 26186, length 40
              21:21:07.227897 IP 192.168.3.32 > 192.168.3.253: ICMP echo reply, id 64919, seq 26186, length 40
              21:21:08.232637 IP 192.168.3.253 > 192.168.3.32: ICMP echo request, id 64919, seq 26188, length 40
              21:21:08.232932 IP 192.168.3.32 > 192.168.3.253: ICMP echo reply, id 64919, seq 26188, length 40
              21:21:09.237604 IP 192.168.3.253 > 192.168.3.32: ICMP echo request, id 64919, seq 26189, length 40
              21:21:09.237875 IP 192.168.3.32 > 192.168.3.253: ICMP echo reply, id 64919, seq 26189, length 40
              

              Where 3.253 is pfsense interface on the dmz network

              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
                steveh_
                last edited by

                Hi Johnpoz,

                CS is the source network (10.0.0.0/24)
                Sonicwall is the destination network (10.200.29.0/24)

                Your screenshot did the trick. I though the interface had to be the source not the destination.

                Cheers

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

                  Great - glad you got it sorted.

                  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
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.