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

    NAT before IPsec VPN on pfsense 2.1

    2.1 Snapshot Feedback and Problems - RETIRED
    3
    22
    17.2k
    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.
    • T
      themr0c
      last edited by

      hmmm, phase 2 is failing

      Jan 26 13:38:28 racoon: ERROR: failed to get sainfo.

      I have defined:

      Local Network : 10.0.0.0/24

      NAT for local network: 192.168.3.1/24 (that is: the local networked i should use for phase2for the other endpoint)

      Did i still misunderstood how it should be configured ?

      Or do i need to remove the 192.168.3.1/24 real interface, that has become useless ?

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

        Thanks, i am now one step further:

        Now i have done following:

        • suppress local interface with phase 2 subnet

        • LAN is 10.0.0.0/24

        • IPsec phase 2 local subnet is 10.0.0.0/24

        • IPsec phase 2 NAT is 192.168.3.1/24 (the subnet required on phase2)

        On the status page, the IPsec connection is reported as down.

        But it seems it is up:  I can ping some host on the remote side, ssh to it (but connection hangs after a few seconds)

        I tried to decrease "System: Advanced: Miscellaneous: Enable MSS clamping on VPN traffic" to 1300, as it fixed same symptoms before, but it doesn't fix this time… Strange. I must be missing some point again.

        1 Reply Last reply Reply Quote 0
        • 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.