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

    IOS (iphone/ipad) & 2.0-RC1 IPsec.. It almost works.

    Scheduled Pinned Locked Moved IPsec
    34 Posts 7 Posters 16.0k 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
      ericab
      last edited by

      hi eazydor

      here is how ive got my IPSec server setup:

      Overview:

      Mobile Clients:

      http://dl.dropbox.com/u/66962/IPSec-pfSense/mobile-clients.jpg

      Phase 1:

      Phase 2:

      now;
      when i switch the listening interface for the ipsec server to my WIFI interface;
      i can connect just fine, but no traffic passes. my wifi network is 192.168.3.0
      it assigns me 192.168.4.1, which is right.

      when i switch the interface to WAN;
      (ive got the firewall rules setup properly to allow UDP 500/4500 on WAN)
      (also have * * * * *; pass all on the IPSec firewall tab.)
      the syslog shows the log from my previous post;
      so not only does it not pass traffic, it wont even connect when listening on the WAN interface.

      not sure if it matters, or if this may be the problem, but my wan interface is actually connected to another upstream router. (dont ask)
      the pfsense box's WAN IP is on the DMZ of the upstream router, and the upstream router IS set to port forward ports 500, and 4500 UDP to pfsense WAN address; aka 192.168.1.142

      Internet –-----> Cable Modem -------> Router (its local LAN is 192.168.1.1/24)--------> (wan address is 192.168.1.142) pfSense --------> my local LAN (192.168.2.0/24)

      1 Reply Last reply Reply Quote 0
      • E
        eazydor
        last edited by

        @ericab try this:

        disable provide network list
        enable nat traversal

        under firewall - nat - outbound

        set to manual
        create new rule
        if wan
        proto any
        src network 192.168.3.0/24 (assuming your wifi is your local network)
        src port blank
        dst not enable inverse option
        dst type any
        dst port blank
        trans addr if adress
        save & apply

        1 Reply Last reply Reply Quote 0
        • E
          ericab
          last edited by

          eazydor;

          well something has changed, im not sure if its progress… here is the new log after applying your settings:

          Apr 27 19:49:19 	racoon: ERROR: phase1 negotiation failed due to time up. feabee14d99e6364:991e2e9cbef177e2
Apr 27 19:49:09 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:59 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:49 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:39 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:38 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:38 	racoon: NOTIFY: the packet is retransmitted by 192.168.1.142[500] (1).
Apr 27 19:48:35 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:35 	racoon: NOTIFY: the packet is retransmitted by 192.168.1.142[500] (1).
Apr 27 19:48:32 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:32 	racoon: NOTIFY: the packet is retransmitted by 192.168.1.142[500] (1).
Apr 27 19:48:29 	racoon: [Self]: [192.168.1.142] ERROR: ignore the packet, received unexpecting payload type 1.
Apr 27 19:48:29 	racoon: INFO: Adding xauth VID payload.
Apr 27 19:48:29 	racoon: [Self]: [192.168.1.142] INFO: Hashing 192.168.1.142[500] with algo #2
Apr 27 19:48:29 	racoon: [Self]: [192.168.1.142] INFO: Hashing 192.168.1.142[500] with algo #2
Apr 27 19:48:29 	racoon: INFO: Adding remote and local NAT-D payloads.
Apr 27 19:48:29 	racoon: [Self]: [192.168.1.142] INFO: Selected NAT-T version: RFC 3947
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: DPD
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: CISCO-UNITY
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
Apr 27 19:48:29 	racoon: INFO: received Vendor ID: RFC 3947
Apr 27 19:48:29 	racoon: INFO: begin Aggressive mode.
Apr 27 19:48:29 	racoon: [Self]: INFO: respond new phase 1 negotiation: 192.168.1.142[500]<=>192.168.1.142[500]

          192.168.1.142 is my WAN address.

          but whats this :  ERROR: ignore the packet, received unexpecting payload type 1.

          1 Reply Last reply Reply Quote 0
          • E
            eazydor
            last edited by

            i have tested your setup with my recommendations and it works flawlessly, at least for me and many people in this forum who have reported the same about this config. furthermore can't i see theoretically why it shouldn't work. so i think i can't help you further than that..

            1 Reply Last reply Reply Quote 0
            • E
              eazydor
              last edited by

              eventually you could try to force nat traversal.. see if that helps.. what ios version are you on?

              1 Reply Last reply Reply Quote 0
              • E
                ericab
                last edited by

                eazydor;

                ill try forcing nat-t

                ios v 4.3.0;  ipad2.

                possibly i should just give up and hope for a jailbreak so i can get openvpn on it. argg

                1 Reply Last reply Reply Quote 0
                • E
                  eazydor
                  last edited by

                  i know. ipsec can be hurt so bad. while openvpn is flying so light.. but these money making morons at cupertino will never let us run this natively.

                  1 Reply Last reply Reply Quote 0
                  • _
                    _igor_
                    last edited by

                    eazydor: your right, with network list enable it routes dircty to wan. shit. No traffic to wan via the tunnel. Outbound nat doesn't work here too. I loose all connect, including the lan access is dead.
                    without the outbound nat entry:
                    What i see is that all traffic ends at the pfsense-lan. DNS is seen at the firewall-log, but no answer is getting back to the phone. hmmm
                    A traceroute from phone via the tunnel ends without any answer.
                    ping is the same. i can ping all lan-clients, but wan is inaccessible.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eazydor
                      last edited by

                      the problem, why i added this nat rule, was that ipsec-clients where talking to wan with their local ipsec-pool addresses. the servers obviously dropped the request since the origin was a private ip. this meant that every outbound traffic wasn't translated to the wan address and the server you´re connecting to doesnt know where to send the packet back. try doing a tcpdump on your wan interface/address and you should see clients doing request with their local ipsec-ip's and not getting replys. after you set the rule correctly you should see the same but clients doing request with the address of your wan interface and getting replys. if you can see the replys, the address translation is working and everything should be fine.

                      1 Reply Last reply Reply Quote 0
                      • _
                        _igor_
                        last edited by

                        clearly no. When i set up the nat forwarding, i instantly loose completely all access to the pfsense. I don't know why but tested that 3 times with same end. I'll try to setup the whole pfsense newly and try again.

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