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

    NAT before IPsec VPN on pfsense 2.1

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    22 Posts 3 Posters 17.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.
    • E
      eri--
      last edited by

      Well what you actually want is a 192.168.3.1/32 since you only say that address is allowed.
      Otherwise it generates a binat rule which might not be what you expect.

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

        Thanks for your help, very appréciated ! Help on IRC was also usefull !

        I created a phase 2 with my LAN subnet (10.0.0.0/24) and NAT as 192.168.3.1/32 and it's working correctly for one of the two tunnels.

        For the second tunnel, i can for example ssh to a server, but connection gets rapidly dropped. For the same symptoms on 2.0, I had to adjust MSS clamping to remote MTU (1420) - 40, that is 1380. This time this doesn't solve the connection issue.

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by

          You have 2 tunnels with the same phase2?
          That's a bit….

          Without posting more detail i cannot help you.

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

            I have 2 different phase1: "A" and "B".

            Each phase 1 has one unique phase2, each one is with subnet 192.168.3.1/24 on my side.

            For first remote (phase 1 "A"),  their firewall only accepts traffic from 192.168.3.1, therefore i need to NAT before IPsec.
            I configured the phase 2 with my LAN subnet as subnet, and the single address 192.168.3.1 as NAT.
            It is working fine now: traffic passes, i can ssh to the hosts, browse the webservers out there from my LAN. Problem solved. Yepee.

            For the second remote (phase 1 "B"), traffic from the whole subnet 192.168.3.1/24 is accepted, but not traffic from my LAN (10.0.0.0/24), therefore i also need to NAT befor IPsec.
            I configured the phase 2 with my LAN subnet as subnet, and the subnet 192.168.3.1/24 as NAT.
            From LAN I can ping some host on the other side, ssh into it, but connection hangs if i run, for example, top. Traffic from monitoring agents is ok. When connection hangs, i get lots of blocked traffic in the firewall log, but the firewall is fully open.
            With pfsense 2.0, i had the same symptom: connection hanging, and it was fixed by fixing MSS clamping to 1380 (MTU of remote peer is 1420).
            This time, it doesn't help.

            Which other details could be usefull to you ?

            Do you need the logs from ipsec ? some logs from firewall ? some packet capture log ?

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Put ipsec in verbose mode and give me that.

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

                here it is: hope 150 last lines is enough ?

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

                  that's more complete: full log from racoon restart, until  i get a connection, ssh into a host, and get blocked.

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

                    hum, it seems it has been truncated. In the log after the restart you can see things happning for both ipsec tunnels. tunnel "A" is not green in the status interface, but it is usable. tunnel "B" is just half-working.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eri--
                      last edited by

                      On the next snapshot the status page should be fixed.

                      For the second tunnel can you show me the /tmp/rules.debug file by anonimizing the ips?
                      I am saying this since the nat rules for the same subnet are generated and your first tunnel rule might be impacting your second one.

                      I removed previous dump of you since your private keys are pasted in there and your ips as well :)

                      1 Reply Last reply Reply Quote 0
                      • E
                        eri--
                        last edited by

                        Thank you for the ruleset and information.
                        It seems that mss clamping was a bit broken for ipsec on 2.1, please try with the next coming snapshot or gitsync it should behave better.

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

                          Thanks a lot !

                          Sorry for the last question: When will the next coming snapshot published ?

                          1 Reply Last reply Reply Quote 0
                          • E
                            eri--
                            last edited by

                            It takes around 8 hours usually but it sometimes is a bit faster.
                            For you gitsync should be easier, check one of the sticky topics on it.

                            The related change is this https://github.com/bsdperimeter/pfsense/commit/af982472816c43827177e499011b92531ba40d72

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

                              gitsync worked like a charm, issue is fixed, many many many thanks !

                              1 Reply Last reply Reply Quote 0
                              • N
                                namtab
                                last edited by

                                I had the same problem on 2.0.2, so I was using an additional NIC just for having a correct local subnet for IPSec.. I guess I could've tried replacing the bogus NIC with a Virtual IP on the LAN subnet..

                                Anyway, I just crossed fingers and upgraded to 2.1-BETA1 (i386) built on Thu Jan 31 12:38:17 EST 2013 then I followed your steps.

                                Now I have:

                                • in Advanced > Miscellaneous checked Enable MSS clamping on VPN traffic and set it to 1200

                                • IPSec Phase 1 setup correctly

                                  • IPSec Phase 2 with
                                    Local Network 192.168.111.0/24 (real LAN)
                                    NAT/BINAT single address 192.168.36.129 (from remotely imposed 192.168.36.129/24 subnet)
                                    Remote subnet 192.168.36.0/25

                                and got phase 2 with NAT working… "Yippee ki-yay, mf!"

                                One last glitch that bugs me: the Status > IPSec page still shows the tunnel as down  ???, even though log says

                                INFO: ISAKMP-SA established

                                and

                                INFO: IPsec-SA established

                                , and traffic gets through normally…

                                Can this log message be relevant

                                racoon: NOTIFY: no in-bound policy found: 192.168.36.0/25[0] 192.168.111.0/24[0] proto=any dir=in

                                ?

                                I already have a Firewall rule on the IPsec interface that allows all traffic through.

                                Did I miss anything or is this issue still on the devs' radar ?

                                Now if only version 2.1 had a PPTP helper, allowing multiple distinct outbound GRE sessions to the same remote IP, I'd be the happiest pfSense user of all time!  ::)

                                1 Reply Last reply Reply Quote 0
                                • E
                                  eri--
                                  last edited by

                                  @namtab:

                                  One last glitch that bugs me: the Status > IPSec page still shows the tunnel as down  ???, even though log says

                                  INFO: ISAKMP-SA established

                                  and

                                  INFO: IPsec-SA established

                                  , and traffic gets through normally…

                                  I pushed a fix for this but will double check.

                                  Can this log message be relevant

                                  racoon: NOTIFY: no in-bound policy found: 192.168.36.0/25[0] 192.168.111.0/24[0] proto=any dir=in

                                  ?

                                  No worries about it. Maybe need to remove the warning completely but its because you are natting that the warning shows up.

                                  Now if only version 2.1 had a PPTP helper, allowing multiple distinct outbound GRE sessions to the same remote IP, I'd be the happiest pfSense user of all time!  ::)

                                  I am not sure for 2.1 it will make it :)

                                  1 Reply Last reply Reply Quote 0
                                  • N
                                    namtab
                                    last edited by

                                    I'm on the latest build and the Status problem is still there, precisely yellow.

                                    The tunnel is by all means up, traffic gets around correctly.

                                    Can the Status be determined as yellow because of the "ERROR: such policy already exists. anyway replace it: " messages in the log (which I have no idea why they come up)?

                                    This is /var/etc/spd.conf

                                    spdadd -4 192.168.111.254/32 192.168.111.0/24 any -P out none;
spdadd -4 192.168.111.0/24 192.168.111.254/32 any -P in none;
spdadd -4 192.168.111.0/24 192.168.36.0/25 any -P out ipsec esp/tunnel/192.168.112.1-{remote tunnel public ip}/unique;
spdadd -4 192.168.36.0/25 192.168.36.129/32 any -P in ipsec esp/tunnel/{remote tunnel public ip}-192.168.112.1/unique;

                                    This is my IPSec log

                                    
Feb 2 00:54:32	racoon: [IPSec client 1]: INFO: IPsec-SA established: ESP 192.168.112.1[500]->{remote tunnel public ip}[500] spi=2237067141(0x8556ef85)
Feb 2 00:54:32	racoon: [IPSec client 1]: INFO: IPsec-SA established: ESP 192.168.112.1[500]->{remote tunnel public ip}[500] spi=85261209(0x514fb99)
Feb 2 00:54:32	racoon: INFO: Adjusting peer's encmode UDP-Tunnel(61443)->Tunnel(1)
Feb 2 00:54:32	racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Feb 2 00:54:32	racoon: WARNING: attribute has been modified.
Feb 2 00:54:32	racoon: INFO: received RESPONDER-LIFETIME: 4608000 kbytes
Feb 2 00:54:32	racoon: INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->61443).
Feb 2 00:54:32	racoon: [IPSec client 1]: INFO: initiate new phase 2 negotiation: 192.168.112.1[4500]<=>{remote tunnel public ip}[4500]
Feb 2 00:54:31	racoon: [IPSec client 1]: INFO: ISAKMP-SA established 192.168.112.1[4500]-{remote tunnel public ip}[4500] spi:1a77e52bf34f298b:b9d50cec11c73ffb
Feb 2 00:54:31	racoon: WARNING: port 4500 expected, but 0
Feb 2 00:54:31	racoon: [IPSec client 1]: INFO: KA list add: 192.168.112.1[4500]->{remote tunnel public ip}[4500]
Feb 2 00:54:31	racoon: INFO: NAT detected: ME
Feb 2 00:54:31	racoon: INFO: NAT-D payload #1 verified
Feb 2 00:54:31	racoon: [IPSec client 1]: [{remote tunnel public ip}] INFO: Hashing {remote tunnel public ip}[500] with algo #1
Feb 2 00:54:31	racoon: INFO: NAT-D payload #0 doesn't match
Feb 2 00:54:31	racoon: [Self]: [192.168.112.1] INFO: Hashing 192.168.112.1[500] with algo #1
Feb 2 00:54:31	racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Feb 2 00:54:31	racoon: INFO: received Vendor ID: DPD
Feb 2 00:54:31	racoon: INFO: received Vendor ID: CISCO-UNITY
Feb 2 00:54:31	racoon: INFO: Adding remote and local NAT-D payloads.
Feb 2 00:54:31	racoon: [Self]: [192.168.112.1] INFO: Hashing 192.168.112.1[500] with algo #1
Feb 2 00:54:31	racoon: [IPSec client 1]: [{remote tunnel public ip}] INFO: Hashing {remote tunnel public ip}[500] with algo #1
Feb 2 00:54:31	racoon: [IPSec client 1]: [{remote tunnel public ip}] INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02
Feb 2 00:54:31	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Feb 2 00:54:31	racoon: INFO: begin Identity Protection mode.
Feb 2 00:54:31	racoon: [IPSec client 1]: INFO: initiate new phase 1 negotiation: 192.168.112.1[500]<=>{remote tunnel public ip}[500]
Feb 2 00:54:31	racoon: [IPSec client 1]: INFO: IPsec-SA request for {remote tunnel public ip} queued due to no phase1 found.
Feb 2 00:54:31	racoon: NOTIFY: no in-bound policy found: 192.168.36.0/25[0] 192.168.111.0/24[0] proto=any dir=in
Feb 2 00:54:05	racoon: ERROR: such policy already exists. anyway replace it: 192.168.36.0/25[0] 192.168.36.129/32[0] proto=any dir=in
Feb 2 00:54:05	racoon: ERROR: such policy already exists. anyway replace it: 192.168.111.0/24[0] 192.168.36.0/25[0] proto=any dir=out
Feb 2 00:54:05	racoon: ERROR: such policy already exists. anyway replace it: 192.168.111.0/24[0] 192.168.111.254/32[0] proto=any dir=in
Feb 2 00:54:05	racoon: ERROR: such policy already exists. anyway replace it: 192.168.111.254/32[0] 192.168.111.0/24[0] proto=any dir=out
Feb 2 00:54:05	racoon: INFO: unsupported PF_KEY message REGISTER
Feb 2 00:54:05	racoon: [Self]: INFO: 192.168.112.1[500] used as isakmp port (fd=15)
Feb 2 00:54:05	racoon: [Self]: INFO: 192.168.112.1[500] used for NAT-T
Feb 2 00:54:05	racoon: [Self]: INFO: 192.168.112.1[4500] used as isakmp port (fd=14)
Feb 2 00:54:05	racoon: [Self]: INFO: 192.168.112.1[4500] used for NAT-T
Feb 2 00:54:05	racoon: INFO: Reading configuration from "/var/etc/ipsec/racoon.conf"
Feb 2 00:54:05	racoon: INFO: @(#)This product linked OpenSSL 1.0.1c 10 May 2012 (http://www.openssl.org/)
Feb 2 00:54:05	racoon: INFO: @(#)ipsec-tools 0.8.1 (http://ipsec-tools.sourceforge.net)
                                    1 Reply Last reply Reply Quote 0
                                    • N
                                      namtab
                                      last edited by

                                      anyone?

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