No.
workgroups are based on UDP broadcasts.
Broadcasts wont go over a router.

But you can access windows shares directly via the IP.

So while you cannot access a workgroup, yes you can access windows-shares.

AFAIK, running with the MTU at 1400 should not cause any issues. Your box will have to work slightly harder, but unless you hardware is already running near capacity, it shouldn't be a problem. Ideally, you could get the equipment that is causing the issue fixed and set the MTU back, but this is not always possible. I would trace the route and do some tests. With more specific information, it might be easier to get your ISP to investigate. As for the remote sites, they should be fine with their default MTUs.

Ipcop and pfsense works as it should in 1.2 release. I think you should check you config again…., is your ruleset in pfsense OK?

Got it!  It was a problem with NAT-T on the Cisco side.  Got the remote admin to send me some screenshots and was able to get him to enable NAT-T traversal on his end.  So the current working config is:

Local Subnet –-- pfSense ---- Internet ---- Cisco PIX Firewall ---- Cisco VPN Concentrator ---- Remote Subnet

Thanks for the help!

-THX2000

I am unclear of what you want.  Do you want to send internet traffic through the client vpn connection so that to access the internet you have to do so via the pfsense gateway?

I think NAT-T isn´t working XOR supported in 1.21!

If NAT-T works in 1.21 would be a new information for me…....

Nobody knows if it is possible to connect two servers with NAT'ed WAN addresses ?

if you have multiple dynamic tunnels how would that affect the script?
rc

The tunnel takes care of the routing between the sites of the tunnel. the network 10.1.x.x will know where to find 192.168.200.X. For the 10.2.x.x network you will need to add a static route (no commands just add it in static routes in the GUI) it should look like: subnet 10.1.x.x /16 gateway central office.

Do the same on the 10.2.x.x end and make sure that the rules allow the traffic!

Yes, it is. Or pretty much.
From the Wikipedia article: http://en.wikipedia.org/wiki/Rijndael
Strictly speaking, AES is not precisely Rijndael (although in practice they are used interchangeably) as Rijndael supports a larger range of block and key sizes; AES has a fixed block size of 128 bits and a key size of 128, 192, or 256 bits, whereas Rijndael can be specified with key and block sizes in any multiple of 32 bits, with a minimum of 128 bits and a maximum of 256 bits.

No - we never did get this resolved.

We engaged the contractor's parent company to see if they could enable NAT traversal, or at least look into it - but beyond saying that they would look into it, were not able to get any attention on the topic.  The immediate project need has diminished - as the initial scope was completed - but I envision this coming back up again soon.  If I knew exactly what they were doing on their end I would try to reproduce the scenario, but as it stands we're at a dead-end until it the need comes back up, or until we run into a similar issue with a different client.

If you make any progress on this in the iterim - I would love to hear about it - please post and/or PM me.  I'll of course do the same if/when it becomes an issue again for us.

Thanks!

NM.  I just had someopne install pfsense on the smoothwall machine.  Too much hassle otherwise.

Ok, no problem, have fun
Greetings from Germany
heiko

bump…
I too am interested in a solution as such. I am under the impression you need to make an ipsec rule that allows traffic from 0.0.0.0 to any or something along those lines?

Another solution is to pitch in on the existing bounty. http://forum.pfsense.org/index.php/topic,10570.0.html