FYI,

AES > 128 with glxsb is not currently supported in any version of FreeBSD:

http://www.freebsd.org/cgi/query-pr.cgi?pr=166508

Thanks,

Todd

I have a similar situation, thanks to the way Comcast's business modems work.

When you say you are "NATed," does that mean you have a 1-to-1 NAT set up from the gateway to your pfSense box, or that the pfSense box is simply behind a NAT?

Hi,

need help, follow everything like the above threads..
but my ICS still cannot connect to pfsense ipsec

below is the log
Jul 12 08:43:45 10.10.20.1 racoon: INFO: respond new phase 1 negotiation: x.x.x.x[500]<=>36.37.233.249[23187]
Jul 12 08:43:45 10.10.20.1 racoon: INFO: begin Aggressive mode.
Jul 12 08:43:45 10.10.20.1 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Jul 12 08:43:45 10.10.20.1 racoon: INFO: received Vendor ID: RFC 3947
Jul 12 08:43:45 10.10.20.1 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 12 08:43:45 10.10.20.1 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 12 08:43:46 10.10.20.1 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
Jul 12 08:43:46 10.10.20.1 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Jul 12 08:43:46 10.10.20.1 racoon: INFO: received Vendor ID: CISCO-UNITY
Jul 12 08:43:46 10.10.20.1 racoon: INFO: received Vendor ID: DPD
Jul 12 08:43:46 10.10.20.1 racoon: [36.37.233.249] INFO: Selected NAT-T version: RFC 3947
Jul 12 08:43:46 10.10.20.1 racoon: INFO: Adding remote and local NAT-D payloads.
Jul 12 08:43:46 10.10.20.1 racoon: [36.37.233.249] INFO: Hashing 36.37.233.249[23187] with algo #2 (NAT-T forced)
Jul 12 08:43:46 10.10.20.1 racoon: [x.x.x.x] INFO: Hashing x.x.x.x[500] with algo #2 (NAT-T forced)
Jul 12 08:43:46 10.10.20.1 racoon: INFO: Adding xauth VID payload.
Jul 12 08:43:46 10.10.20.1 racoon: INFO: NAT-T: ports changed to: 36.37.233.249[24964]<->x.x.x.x[4500]
Jul 12 08:43:46 10.10.20.1 racoon: INFO: NAT-D payload #0 doesn't match
Jul 12 08:43:46 10.10.20.1 racoon: INFO: NAT-D payload #1 doesn't match
Jul 12 08:43:46 10.10.20.1 racoon: INFO: NAT detected: ME PEER
Jul 12 08:43:46 10.10.20.1 racoon: INFO: Sending Xauth request
Jul 12 08:43:46 10.10.20.1 racoon: INFO: ISAKMP-SA established x.x.x.x[4500]-36.37.233.249[24964] spi:e873490ee429fe8e:8d3f55d60b590232
Jul 12 08:43:46 10.10.20.1 racoon: [36.37.233.249] INFO: received INITIAL-CONTACT
Jul 12 08:43:46 10.10.20.1 racoon: INFO: Using port 0
Jul 12 08:43:46 10.10.20.1 racoon: INFO: login succeeded for user "test"

could someone help me…

on the other hand...my iPhone and iPad can connect perfectly

i understand..
PFSENSE is still super..
i am loving it…
thankx..

Ah, ok, I misunderstood- I thought you were connecting to the VPN on the same router you were sitting behind.

It's possible your firewall at work is blocking ESP or doing something else that will break ISAKMP from the iPhone.

Make sure on your firewall at home you have NAT Translation forced on for IPsec, and if you can check on the work firewall, make sure it allows you to use udp/4500 outbound as well as udp/500 and esp if it can't do NAT-T for some reason.

If you are at a remote location and it works from 3G but not their wireless, there may not be anything you can do to fix their wireless if they're blocking it, especially if that blocking is done on purpose to prevent exactly what you're attempting.

You could always jailbreak and run OpenVPN on a UDP or TCP port they allow out, but depending on what they pass/block through your work firewall that may or may not work either.

From which end are you having trouble?

How is the firewall in your pfSense box configured for the IPsec and LAN interface? And which connections are you not getting through?

Regards,
Anders

pick your own: http://doc.pfsense.org/index.php/Category:IPsec

Mobile IPsec is really meant to be for remote devices, not local. You can't make more than one Phase 1.

If it were OpenVPN you could just add a port forward to make it available on multiple interfaces, but IPsec is much less forgiving.

Why do you need IPsec on top of your Wifi?

Never mind–I discovered that there was a SMB deny rule on the Watchguard site. It was created by my predecessor and I didn't realize it would override the tunnel allow any/any rule.

while I'm REALLY new to pfsense (like 4 days old haha), I had a problem similar over my ipsec vpn. I could ping from the remote office to the main office, but not the other way around.

I ended up going to Firewall -> Rules -> IPsec @ the remote office, and made an "any" rule (any protocol, source, port, destination, gateway). Once I did that, I could ping and traceroute both ways across the link.

Basically, you have to treat the IPsec tunnel as any other network adapter it seems. Hope this helps.

Hello,

i thought, there is just 1 post, but http://forum.pfsense.org/index.php/topic,50914.0.html
It's the same, just in the german support.

We should close this one and keep going in the german one …

My german is also better  ;D

Greetings / Gruß

Sanches

Apparently side "B" needs some rules to allow IPSEC from "A".  However "A" needed no such rules.(which is the part that confused me.)  Adding A->(any WAN) seems to have resolved the problem.

There is data on the SAD entries going from you to the remote site - there is no data on the return SAs. That implies that they are blocking the traffic or it's being ignored/misrouted on the return. You side may be setup right. I'd focus on the remote.

The packets being blocked are ACK packets, so as cmb said, asymmetric routing is the most likely explanation.

Thank you that did the trick.

That's for a different type of mobile IPsec. You're using xauth, which truly means the user's password, doesn't use user pre-shared keys.

cmb,

Not really, TMG is configured only time-based. Also, it not only drops the connection after a certain amount of bytes, it could even finish copying the entire file, like I said one in 10 to 12 times.

Thanks.