No matter of priority between IPSEC and local atached network (it seems that IPSEC gets over locals). I think U have to play more with subneting/superneting techniques.

The problem is that 10/8 on A you have to use eg 10.2.0.0/15 which includes 10.2/24 and 10.3/24 networks:

(10.2/15)
      box A <–-(tun A-C)---> ipsec to other networks, works fine
        A
        |
    (tun A-B)
        |
        V
      box B                     
    (10.1/16)                 
    ----|----                 
    |        |
  LAN    OPT1
10.1/24  10.1.1/24

Solved - for those who are interested:

I made my Certs with XCA (very good Opensource CA solution) … and there i defined inside the Certificate no Subject Alternative Name ... after i created new certs with IP:123.123.123.123 (same as CN) as a alternative name, all works as it should!

Like i said i use this on M0n0wall.
Could it be the type of tunnel?

this is the rest of my ipsec tunnel config

Interface            WAN
Local Subnet        Type Network
                    192.168.0.0 /24
Remote Subnet    192.168.1.0 /24
Remote Gateway    244.244.244.244

Description test

Phase 1 proposal (Authentication)

Negotiation mode  Aggressive
My identifier        My ipadress
Encryption algorithm    3Des
Hash algorithm    SHA1
DH key group    2
Authentication method    pre shared key
Pre-Shared Key      your preshared key  (i use different ones for each tunnel.)

Phase 2 proposal (SA/Key Exchange)

Protocol    ESP
Encryption algorithms    3Des
Hash algorithm    SHA1
PFS key group    off

that is the rest of my config.
I am not able to test pfsense for the tunnel at the moment.

regards,
Johan

Hello, thank you very much for your advice.
Unfortunately I cannot rely on "I assume they are not going to change IPs". In my first post, I said that firewall rules on IPSEC port are not an option. I don't know all of these guys well and some are quite savvy. - This is about highest possible security and not having to spend a dedicated hardware each.
I guess OpenVPN would be the better choice, but some of the users are connecting their IPSec capable DSL routers and of course those don't do OpenVPN. :-(
Maybe there is a more advanced option? Do you know of any options I could feed directly into the config (non-GUI)?

Thanks!

I have started to see this problem now as well on a previously working (not changed IPSec)
tunnel after testing the 1.2 beta / RC versions.

I will do a test with an older version to see if it works again.

///Dan Lundqvist

That's normal and if you search the forum you'll find many posts asking the same question  ;)

Not all guis have all settings at one page. Some vendors prefer to have multiple pages for that and reference one of the settings from another screen. Other vendors hardcode some of the settings and you have to know what they have set them to on the other end. I have pfSense systems connected to several other products via ipsec. It's sometimes hard to find out how to configure them but in the end it always worked for me.

This was discussed yesterday.  Please search before blindly opening forum topics.

It must be at least natting which can cause problems as you have a private IP behind it.

I can confirm that logging UDP traffic works now with Beta 2  ;D

Will test the other problem soon.

Greets

Dave

We're new to pfsense, and just starting to test. What you're describing is possible. You would setup different weights for routes, and Cisco has a tracking feature that would ping an IP address. When the preferred route fails, you would alter the route weight and move the packets over the backup connection.

We are still having this problem  :(,
Not sure if anyone else can help us out but here's what the ASA5510 looks like:

A.A.A.A = Remote LAN

B.B.B.B = Remote public IP

Y.Y.Y.Y = Local LAN

Z.Z.Z.Z = Local public IP

:

ASA Version 7.0(5)

!

interface Ethernet0/0

speed 100

duplex full

nameif PUBLIC

security-level 0

ip address Z.Z.Z.Z 255.255.255.0

!

interface Ethernet0/2

nameif PRIVATE

security-level 100

ip address Y.Y.Y.Y 255.255.255.0

!

access-list PUBLIC_access_in extended permit ip A.A.A.A 255.255.255.0 Y.Y.Y.Y 255.255.255.0
access-list nonat extended permit ip Y.Y.Y.Y 255.255.255.0 A.A.A.A 255.255.255.0
access-list PUBLIC_cryptomap_20 extended permit ip Y.Y.Y.Y 255.255.255.0 A.A.A.A 255.255.255.0
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto map PUBLIC_map 20 match address PUBLIC_cryptomap_20
crypto map PUBLIC_map 20 set peer B.B.B.B crypto map PUBLIC_map 20
set transform-set ESP-3DES-MD5
crypto map PUBLIC_map interface PUBLIC
isakmp identity address
isakmp enable PUBLIC
isakmp policy 10
authentication pre-share
isakmp policy 10
encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 1
isakmp policy 10 lifetime 3600
tunnel-group B.B.B.B type ipsec-l2l
tunnel-group B.B.B.B ipsec-attributes  pre-shared-key * 
peer-id-validate nocheck
tunnel-group-map default-group B.B.B.B no vpn-addr-assign dhcp no vpn-addr-assign local

Its help, thanks Heiko…

@heiko:

Scott wrote on the mailing list:

Try a snapshot later today or run this command and reboot:

chmod a+rx /usr/local/bin/*.sh

i've been having same issues alot but after cmd and hoba suggested to check settings i found that lifetime on all routers if off. after adjustment everything works greate… but you gonna have to get settings from the other end of the tunnel to match them on your end.

My question is not about shaping ipsec traffic.. but i think i found the answer:

The original TOS field is copied to the encapsulating IP header, so the qos information still
remains on the encrypted packet and can be routed/queued/prioritized accordingly.

Regards,
Reto