It really depends on on how your ISP delivers those IPs to you.

@spiritbreaker:

Hi,

plz provide more details.

How your phase1 and 2 looks like?

cya

Hi;
Cisco config looks like this:

interface Tunnel115
ip vrf forwarding apsdtp
ip address 192.168.115.1 255.255.255.0
tunnel source FastEthernet0/1
tunnel destination PUBLIC_IP_SITEB
tunnel mode ipsec ipv4
tunnel protection ipsec profile s2s-ap
end

crypto ipsec profile s2s-ap
set transform-set s2s-TSET

crypto isakmp key KEEEY address 78.x.x.x5 no-xauth

On the pfsense I have used ordinary IPSEC configuration which work without any problem when the IPSEC tunnel is termineted on physically interface not vti

PFsens:
May 11 17:54:19 racoon: [do-tsp-monitoring]: INFO: IPsec-SA established: ESP 78.x.x.x5[500]->194.x.x.2xx[500] spi=4174818755(0xf8d6adc3)
May 11 17:55:07 racoon: [do-tsp-monitoring]: INFO: respond new phase 2 negotiation: 78.x.x.x5[500]<=>194.x.x.2xx[500]
May 11 17:55:07 racoon: ERROR: failed to get sainfo. May 11 17:55:07 racoon: ERROR: failed to get sainfo.
May 11 17:55:07 racoon: [do-tsp-monitoring]: [194.x.x.2xx] ERROR: failed to pre-process ph2 packet [Check Phase 2 settings, networks] (side: 1, status: 1).

on the cisco:
Interface: Tunnel115
Session status: UP-ACTIVE
Peer: 78.x.x.x5 port 500
  IKE SA: local 194.x.x.2xx/500 remote 78.x.x.x5/500 Active
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 0, origin: crypto map
  IPSEC FLOW: permit ip 192.168.115.0/255.255.255.0 192.168.1.0/255.255.255.0
        Active SAs: 2, origin: crypto map

next P2:
*May 11 17:58:29: ISAKMP:(1244): Creating IPSec SAs
*May 11 17:58:29:        inbound SA from 78.x.x.x5 to 194.x.x.2xx (f/i)  0/ 0
        (proxy 192.168.1.0 to 192.168.115.0)
*May 11 17:58:29:        has spi 0xF8D6ADC3 and conn_id 0
*May 11 17:58:29:        lifetime of 3600 seconds
*May 11 17:58:29:        outbound SA from 194.x.x.2xx to 78.x.x.x5 (f/i) 0/0
        (proxy 192.168.115.0 to 192.168.1.0)
*May 11 17:58:29:        has spi  0x72F8D79 and conn_id 0
*May 11 17:58:29:        lifetime of 3600 seconds
*May 11 17:58:29: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:58:29: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:58:29: ISAKMP:(1244):Node -393251934, Input = IKE_MESG_INTERNAL, IKE_GOT_SPI
*May 11 17:58:29: ISAKMP:(1244):Old State = IKE_QM_SPI_STARVE  New State = IKE_QM_R_QM2
*May 11 17:58:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel115, changed state to up
*May 11 17:58:29: ISAKMP (1244): received packet from 78.x.x.x5 dport 500 sport 500 Global (R) QM_IDLE
*May 11 17:58:29: ISAKMP:(1244):deleting node -393251934 error FALSE reason "QM done (await)"
*May 11 17:58:29: ISAKMP:(1244):Node -393251934, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*May 11 17:58:29: ISAKMP:(1244):Old State = IKE_QM_R_QM2  New State = IKE_QM_PHASE2_COMPLETE
*May 11 17:58:38: No peer struct to get peer description
*May 11 17:59:06: No peer struct to get peer description
*May 11 17:59:07: ISAKMP:(0):purging node -120744098
*May 11 17:59:07: ISAKMP:(0):purging node 284091442
*May 11 17:59:17: ISAKMP: set new node 0 to QM_IDLE
*May 11 17:59:17: SA has outstanding requests  (local 102.143.234.116 port 500, remote 102.143.234.144 port 500)
*May 11 17:59:17: ISAKMP:(1244): sitting IDLE. Starting QM immediately (QM_IDLE      )
*May 11 17:59:17: ISAKMP:(1244):beginning Quick Mode exchange, M-ID of 667183992
*May 11 17:59:17: ISAKMP:(1244):QM Initiator gets spi
*May 11 17:59:17: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:17: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:59:17: ISAKMP:(1244):Node 667183992, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
*May 11 17:59:17: ISAKMP:(1244):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
*May 11 17:59:17: ISAKMP:(0):purging SA., sa=6692985C, delme=6692985C
*May 11 17:59:19: ISAKMP:(1244):purging node -393251934
*May 11 17:59:27: ISAKMP:(1244): retransmitting phase 2 QM_IDLE      667183992 …
*May 11 17:59:27: ISAKMP (1244): incrementing error counter on node, attempt 1 of 5: retransmit phase 2
*May 11 17:59:27: ISAKMP (1244): incrementing error counter on sa, attempt 1 of 5: retransmit phase 2
*May 11 17:59:27: ISAKMP:(1244): retransmitting phase 2 667183992 QM_IDLE
*May 11 17:59:27: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:27: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:59:35: No peer struct to get peer description
*May 11 17:59:37: ISAKMP:(1244): retransmitting phase 2 QM_IDLE      667183992 ...
*May 11 17:59:37: ISAKMP (1244): incrementing error counter on node, attempt 2 of 5: retransmit phase 2
*May 11 17:59:37: ISAKMP (1244): incrementing error counter on sa, attempt 2 of 5: retransmit phase 2
*May 11 17:59:37: ISAKMP:(1244): retransmitting phase 2 667183992 QM_IDLE
*May 11 17:59:37: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:37: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:59:40: No peer struct to get peer description
*May 11 17:59:47: ISAKMP: set new node 0 to QM_IDLE
*May 11 17:59:47: SA has outstanding requests  (local 102.143.234.116 port 500, remote 102.143.234.144 port 500)
*May 11 17:59:47: ISAKMP:(1244): sitting IDLE. Starting QM immediately (QM_IDLE      )
*May 11 17:59:47: ISAKMP:(1244):beginning Quick Mode exchange, M-ID of -1574076160
*May 11 17:59:47: ISAKMP:(1244):QM Initiator gets spi
*May 11 17:59:47: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:47: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:59:47: ISAKMP:(1244):Node -1574076160, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
*May 11 17:59:47: ISAKMP:(1244):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
*May 11 17:59:47: ISAKMP:(1244): retransmitting phase 2 QM_IDLE      667183992 ...
*May 11 17:59:47: ISAKMP (1244): incrementing error counter on node, attempt 3 of 5: retransmit phase 2
*May 11 17:59:47: ISAKMP (1244): incrementing error counter on sa, attempt 3 of 5: retransmit phase 2
*May 11 17:59:47: ISAKMP:(1244): retransmitting phase 2 667183992 QM_IDLE
*May 11 17:59:47: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:47: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:59:57: ISAKMP:(1244): retransmitting phase 2 QM_IDLE      -1574076160 ...
*May 11 17:59:57: ISAKMP (1244): incrementing error counter on node, attempt 1 of 5: retransmit phase 2
*May 11 17:59:57: ISAKMP (1244): incrementing error counter on sa, attempt 4 of 5: retransmit phase 2
*May 11 17:59:57: ISAKMP:(1244): retransmitting phase 2 -1574076160 QM_IDLE
*May 11 17:59:57: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:57: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 17:59:57: ISAKMP:(1244): retransmitting phase 2 QM_IDLE      667183992 ...
*May 11 17:59:57: ISAKMP (1244): incrementing error counter on node, attempt 4 of 5: retransmit phase 2
*May 11 17:59:57: ISAKMP (1244): incrementing error counter on sa, attempt 5 of 5: retransmit phase 2
*May 11 17:59:57: ISAKMP:(1244): retransmitting phase 2 667183992 QM_IDLE
*May 11 17:59:57: ISAKMP:(1244): sending packet to 78.x.x.x5 my_port 500 peer_port 500 (R) QM_IDLE
*May 11 17:59:57: ISAKMP:(1244):Sending an IKE IPv4 Packet.
*May 11 18:00:07: ISAKMP:(1244): retransmitting phase 2 QM_IDLE      -1574076160 ...
*May 11 18:00:07: ISAKMP:(1244):peer does not do paranoid keepalives.

*May 11 18:00:07: ISAKMP:(1244):deleting SA reason "Death by retransmission P2" state (R) QM_IDLE      (peer 78.x.x.x5)

on the end I have
Interface: Tunnel115
Session status: UP-NO-IKE
Peer: 78.x.x.x5 port 500
  IKE SA: local 194.x.x.2xx/500 remote 78.x.x.x5/500 Inactive
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 0, origin: crypto map
  IPSEC FLOW: permit ip 192.168.115.0/255.255.255.0 192.168.1.0/255.255.255.0
        Active SAs: 2, origin: crypto map

Hi,

what about step6? there is something wrong..this is not possible with inactive tunnel.

Check ur routing tables, maybe pakets get routed directly. Post ur networkconfig (site1 site2 wan)

Cya

Hi,

sure use Firewall rules.

go to Firewall -> Ipsec and restrict incomming traffic by setting up rules like this:

Example: Rule to permit only HTTP Traffic to ur Site2 LAN:

Proto Source       Port   Destination                   Port  Gateway Queue Schedule Description
  *        site1_lan         *     Site2-LAN net(or IP)      80               * none

Hope This helps.

Cya

You can run tcpdump on the enc0 interface to see what is coming and going in terms of IPsec traffic. No way to do that from the GUI in 1.2.3, if you're on a 2.0 snapshot you should be able to do that from Diagnostics > Packet Capture.

Oh, by the way,

I have no access to the Cisco side, as is configured by the technical staff of a customer, and they will not attend me if I ask them to change any parameter of their server.

Im trying to set a value for dpd as low a 2 seconds, so the tunnel is renegotiated as soon as the peer is dead, but it does not seem to work.

Thanks in advance for any sugestion.

Juan Diego.

@cmb:

You have to disable NAT too via outbound NAT when you're routing public IPs, on all the systems that are routing public IPs.

Great - good advice. I have disabled it on both routers.

Just to summarize to everyone, after upgrading to 2.0 and disabling outbound NAT, IPSEC is passed through from Router1 to Router2.

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.

so i can ignore this warning? i need no revocation list.

like i said, many providers and home routers are blocking esp-traffic, therefore nat-traversal could be a solution. since many networks like hotels, etc.. doesnt allow any traffic appart from http(s) via a proxy, even nat-t would fail. i know of a company which does ipsec over https, like you could do openvpn over https, encapsulating the payload in a ssl-header for avoiding these problems, but how this works exactly, i have no idea..
Glad that's running for you..

Thanks for the tip, that did the trick!  :D

@szop please be aware that by enabling "Provide a list of accessible networks to clients" you do lose your default route trough your tunnel and all of your traffic apart from the traffic eventually defined in the phase 2 local subnet will NOT be sent trough your tunnel.

ok.. maybe that will work. but what is with my iOS devices? For them i have to use PSK + XAuth. And this isn´t possible with a second phase 1  :(

i forgot to say that i´m using the latest 2.0 RC1 build.

edit: ok, now i´m using only PSK´s +Xauth for the roadwarrior connections and it´s working like a charme with greenbow and iOS devices :)

As a follow-up to my own post…

By enabling the " Prefer old IPsec SAs " my problem has been resolved. The IPSec connection still tries for multiple SAD entries but falls back to the proper number, two.

This config option can be found, in version 1.2.3, in the System menu, under Advanced, in the Miscellaneous config options.

Jason

Thank you, it worked!

No under Firewall>Rules, IPsec tab.

Yes, several times. Just make sure the settings match up.