Net to Net one way communication

Have you done a traceroute/tracert to see where the packets are going??
  

Have you done a traceroute/tracert to see where the packets are going??
  

The hit the default gateway and stop there.

Network:
192.168.10.x --Office
192.168.10.1--FW

192.168.2.x--Remote
192.168.2.1--Remote FW

VPN Connection Info:
  000  
000 "Ken__VPN_1"[1]: 192.168.10.0/24===209.98.153.33...68.117.53.91===192.168.1.0/24
000 "Ken__VPN_1"[1]:   CAs: '%any'...'%any'
000 "Ken__VPN_1"[1]:   ike_life: 7800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "Ken__VPN_1"[1]:   policy: PSK+ENCRYPT+TUNNEL; interface: eth1; erouted
000 "Ken__VPN_1"[1]:   newest ISAKMP SA: #6; newest IPsec SA: #7; eroute owner: #7
000 "Ken__VPN_1"[1]:   IKE algorithms wanted: 5_000-1-5, flags=-strict
000 "Ken__VPN_1"[1]:   IKE algorithms found:  5_192-1_128-5, 
000 "Ken__VPN_1"[1]:   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000 "Ken__VPN_1"[1]:   ESP algorithms wanted: 3_000-1, flags=-strict
000 "Ken__VPN_1"[1]:   ESP algorithms loaded: 3_168-1_128, 
000 "Ken__VPN_1"[1]:   ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=
000 "Ryan__VPN_1": 192.168.10.0/24===209.98.153.33...63.228.59.189===192.168.2.0/24
000 "Ryan__VPN_1":   CAs: '%any'...'%any'
000 "Ryan__VPN_1":   ike_life: 7800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "Ryan__VPN_1":   policy: PSK+ENCRYPT+TUNNEL; interface: eth1; erouted
000 "Ryan__VPN_1":   newest ISAKMP SA: #2; newest IPsec SA: #5; eroute owner: #5
000 "Ryan__VPN_1":   IKE algorithms wanted: 5_000-1-5, flags=-strict
000 "Ryan__VPN_1":   IKE algorithms found:  5_192-1_128-5, 
000 "Ryan__VPN_1":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000 "Ryan__VPN_1":   ESP algorithms wanted: 12_128-1, flags=-strict
000 "Ryan__VPN_1":   ESP algorithms loaded: 12_128-1_128, 
000 "Ryan__VPN_1":   ESP algorithm newest: AES_128-HMAC_MD5; pfsgroup=
000 "Ken__VPN_1": 192.168.10.0/24===209.98.153.33...%any===192.168.1.0/24
000 "Ken__VPN_1":   CAs: '%any'...'%any'
000 "Ken__VPN_1":   ike_life: 7800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "Ken__VPN_1":   policy: PSK+ENCRYPT+TUNNEL; interface: eth1; unrouted
000 "Ken__VPN_1":   newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0
000 "Ken__VPN_1":   IKE algorithms wanted: 5_000-1-5, flags=-strict
000 "Ken__VPN_1":   IKE algorithms found:  5_192-1_128-5, 
000 "Ken__VPN_1":   ESP algorithms wanted: 3_000-1, flags=-strict
000 "Ken__VPN_1":   ESP algorithms loaded: 3_168-1_128, 
000 "CPQ__VPN_1": 192.168.10.0/24===209.98.153.33...64.122.70.215===10.0.1.0/24
000 "CPQ__VPN_1":   CAs: '%any'...'%any'
000 "CPQ__VPN_1":   ike_life: 7800s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "CPQ__VPN_1":   policy: PSK+ENCRYPT+TUNNEL; interface: eth1; erouted
000 "CPQ__VPN_1":   newest ISAKMP SA: #1; newest IPsec SA: #4; eroute owner: #4
000 "CPQ__VPN_1":   IKE algorithms wanted: 5_000-2-5, flags=-strict
000 "CPQ__VPN_1":   IKE algorithms found:  5_192-2_160-5, 
000 "CPQ__VPN_1":   IKE algorithm newest: 3DES_CBC_192-SHA-MODP1536
000 "CPQ__VPN_1":   ESP algorithms wanted: 3_000-1, flags=-strict
000 "CPQ__VPN_1":   ESP algorithms loaded: 3_168-1_128, 
000 "CPQ__VPN_1":   ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=
000  
000 #4: "CPQ__VPN_1" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 22765s; newest IPSEC; eroute owner
000 #4: "CPQ__VPN_1" esp.ff914dd@64.122.70.215 esp.ca6f7035@209.98.153.33 tun.1004@64.122.70.215 tun.1003@209.98.153.33
000 #1: "CPQ__VPN_1" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1472s; newest ISAKMP
000 #7: "Ken__VPN_1"[1] 68.117.53.91 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3151s; newest IPSEC; eroute owner
000 #7: "Ken__VPN_1"[1] 68.117.53.91 esp.da567b80@68.117.53.91 esp.ca6f7037@209.98.153.33 tun.1008@68.117.53.91 tun.1007@209.98.153.33
000 #6: "Ken__VPN_1"[1] 68.117.53.91 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 7287s; newest ISAKMP
000 #5: "Ryan__VPN_1" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 327s; newest IPSEC; eroute owner
000 #5: "Ryan__VPN_1" esp.ff197b72@63.228.59.189 esp.ca6f7036@209.98.153.33 tun.1006@63.228.59.189 tun.1005@209.98.153.33
000 #2: "Ryan__VPN_1" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1504s; newest ISAKMP
000 
 

VPN Route Info:

6          192.168.10.0/24:0  -> 10.0.1.0/24:0      => tun0x1004@64.122.70.215:0
2          192.168.10.0/24:0  -> 192.168.1.0/24:0   => tun0x1008@68.117.53.91:0
475        192.168.10.0/24:0  -> 192.168.2.0/24:0   => tun0x1006@63.228.59.189:0

Thanks again,
Ryan  

Has the connection been set up symmetrically?
Is the local on the IPsec settings set to the firewall interface IP?

Also try a ping from webadmin GUI tools; make sure ICMP is turned on (beneath the PF rules menu choice)
  

Thanks for the input, but I double checked everything that was suggested to no avail.

Here is a list of the Packet Filter rules:

1  Any { InternetPorts } CorpWeb2 Allow  
  2  Any { InternetPorts } CorpWeb Allow 
  3  CPQ_LAN Any Internal_Network__ Allow  
  4  Internal_Network__ Any CPQ_LAN Allow  
  5  Ryan_LAN Any Any Allow  
  6  Internal_Network__ Any Ryan_LAN Allow  
  7  Ken_LAN Any Any Allow  
  8  Internal_Network__ Any Any Allow  
  9  Any Any Any Drop 

The LAN on the Office is  MASQ behind one address which is the same address as the VPN Endpoint on the firewall.

Here is a copy of the Routing Table. It looks correct to me.

10.0.1.0/24 dev ipsec0  table 42  scope link 
192.168.2.0/24 dev ipsec0  table 42  scope link 
192.168.1.0/24 dev ipsec0  table 42  scope link 
209.98.153.37 dev eth1  scope link  src 209.98.153.37 
209.98.153.36 dev eth1  scope link  src 209.98.153.36 
209.98.153.35 dev eth1  scope link  src 209.98.153.35 
209.98.153.34 dev eth1  scope link  src 209.98.153.34 
209.98.153.32/29 dev eth1  scope link 
209.98.153.32/29 dev ipsec0  proto kernel  scope link  src 209.98.153.33 
192.168.10.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 209.98.153.38 dev eth1 
broadcast 209.98.153.39 dev eth1  table local  proto kernel  scope link  src 209.98.153.33 
broadcast 209.98.153.39 dev ipsec0  table local  proto kernel  scope link  src 209.98.153.33 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 209.98.153.37 dev eth1  table local  proto kernel  scope host  src 209.98.153.37 
broadcast 209.98.153.37 dev eth1  table local  proto kernel  scope link  src 209.98.153.37 
local 209.98.153.36 dev eth1  table local  proto kernel  scope host  src 209.98.153.36 
broadcast 209.98.153.36 dev eth1  table local  proto kernel  scope link  src 209.98.153.36 
broadcast 192.168.10.255 dev eth0  table local  proto kernel  scope link  src 192.168.10.1 
local 209.98.153.35 dev eth1  table local  proto kernel  scope host  src 209.98.153.35 
broadcast 209.98.153.35 dev eth1  table local  proto kernel  scope link  src 209.98.153.35 
local 209.98.153.34 dev eth1  table local  proto kernel  scope host  src 209.98.153.34 
broadcast 209.98.153.34 dev eth1  table local  proto kernel  scope link  src 209.98.153.34 
local 209.98.153.33 dev eth1  table local  proto kernel  scope host  src 209.98.153.33 
local 209.98.153.33 dev ipsec0  table local  proto kernel  scope host  src 209.98.153.33 
broadcast 209.98.153.32 dev eth1  table local  proto kernel  scope link  src 209.98.153.33 
broadcast 209.98.153.32 dev ipsec0  table local  proto kernel  scope link  src 209.98.153.33 
local 192.168.10.1 dev eth0  table local  proto kernel  scope host  src 192.168.10.1 
broadcast 192.168.10.0 dev eth0  table local  proto kernel  scope link  src 192.168.10.1 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 

Thanks again for any help,
Ryan


  

Simpler test: if you go to the webadmin tools, can you ping the opposing firewall's Internet IP address, both ways (so you will have to have two webadmin sessions...)
  

Thanks again,

Here are the Ping Results:

From remote firewall: 
192.168.2.1 (self)--fine
192.168.10.1(office FW LAN side)--nothing
192.168.10.1(office Server)--nothing

From remote server:
192.168.2.1 (gateway)--fine
192.168.10.1 (office FW LAN side)--fine
192.168.10.200 (office server)--fine

From Office to remote site on FW:
192.168.10.1 (Self)--fine
192.168.2.1 (Remote Firewall)--Nothing
192.168.2.200 (Remote Server)--Nothing

From Office PC to Remote Site:
192.168.10.1 (Gateway)--Fine
192.168.2.1 (Remote Office FW LAN Side)--Nothing
192.168.2.200 (Remote Server)--Nothing

I have all the ICMP options on all firewalls.

Thanks for your continued help,
Ryan
  

Those are the private numbers; also do the Internet addresses of the interfaces, both ways. It will probably work, but I'm just ruling things out...
  

You were correct. (It always pays to stroke someones ego a little!)

From the remote FW and Server I can ping the valid IP of the office and from the Office FW and Client I can ping the remote office Valid IP.

Ryan  

But the ping of the private numbers is still not working?

Correct...

Now here is something really weird. One of the remote locations has a SonicWall to ASL VPN up and working. From the SonicWall site I can get to the Remote ASL site; but from the Office, I still cannot get to any remote private sites?

It appears as though there is either a routing problem or the packets are getting dropped by the rules. I have re-checked each remote site and they all are allowing anything from the Office LAN and the Office LAN is allowing everything from the Remote sites.

It still only works from remote to Office which makes the routing correct...it has to be the rules.

Any thoughts?

Ryan

If the packetfilter rules are dropping the packets, they should show up in the pf logs.