Net to Net one way communication

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.

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

That's what's got me stumped; I was thinking of another test to rule things out. The traceroute shows it going to the firewall, so the VPN on the main firewall must be configured wrong. The rules seem good. Unless it was something weird like some device was duplicating the IP of the firewall...

If some other device was duplicating the IP of the FW, the Ping from ASL WebAdmin should work but from the client should fail both.

If it is a VPN connection problem, why can the remotes connect to the office just fine?

Still confused,
Ryan

Show us your interface and masquerade settings; sanitize your public IPs for security purposes...

Interfaces...

   Up   Internal (Standard ethernet interface)
on eth0 ([unknown vendor / unknown chipset] )   192.168.10.1 / 255.255.255.0
Gateway: none   edit
delete   
     Up   WAN_33 (Standard ethernet interface)
on eth1 ([unknown vendor / unknown chipset] )   x.x.x.x / 255.255.255.248
Gateway: x.x.x.x     
     Up   WAN_34 (Additional address on ethernet interface)
on eth1 ([unknown vendor / unknown chipset] )   x.x.x.x / 255.255.255.255
Gateway: none     
     Up   WAN_35 (Additional address on ethernet interface)
on eth1 ([unknown vendor / unknown chipset] )   x.x.x.x / 255.255.255.255
Gateway: none  
     Up   WAN_36 (Additional address on ethernet interface)
on eth1 ([unknown vendor / unknown chipset] )   x.x.x.x / 255.255.255.255
Gateway: none 
     Up   WAN_37 (Additional address on ethernet interface)
on eth1 ([unknown vendor / unknown chipset] )   x.x.x.x / 255.255.255.255
Gateway: none 


NAT rules:

DNAT Mail   All -> WAN_34_Interface__ / Any   None   CorpWeb2     
  DNAT Web   All -> WAN_36_Interface__ / Any   None   CorpWeb     
  DefaultMASQ   Internal_Network__ -> All / All   MASQ__WAN_33   None     
  SNAT Mail   CorpWeb2 -> All / Any   WAN_34_Interface__   None   
  SNAT Web   CorpWeb -> All / Any   WAN_36_Interface__   None    
  TBDNAT   Any -> WAN_37_Interface__ / Any   None   ryanws     
  TBSNAT   ryanws -> Any / Any   WAN_37_Interface__   None 


Ryan

I should add that CorpWeb and Corpweb2 are the same physical machine with multiple IP addresses on the same box. I am using host headers for multiple Web sites. (Although this should not matter.)

Ryan

Are the three VPN endpoints all Astaro?
Or are some something else??

Two to ASL one to SonicWall.

One of the other ASL has a connection to the Sonicwall as well

The box you're trying to ping at the branch office from the main office; what is its gateway set to? Astaro??

No, all remotes (including the office) have their default gateway's pointing to their respective gateway's.

As a single branch, each ASL is working fine. The office only fails when the request initiates from the office.

Thanks again,
Ryan

When you ping the branch from the main office, the only way the ping service on the machine you're pinging in the branch office will know to pass back packets from foreign networks (such as the main office) is to have its gateway set to Astaro. If you are using another device for the gateway in the branch office, then you will need to add a route for the main office's 192 network to point to the Astaro in the branch office.

Another option is to add a route on the branch office machine you're pinging, but if you want to do this for more than one machine, it makes more sense to program the route info into a shared routing gateway device...