Double NAT over VPN Browsing Problem

I have 493 behind a NAT’D Public…one to one NAT’d.

Exterior of head end router is 1.1.1.1 …NAT’d to 10.10.1.15…

the 493’s Eth1 is 10.10.1.15 interior network 192.168.28.0/24

one VPN constructed over 10.10.1.15 to a hub (2.2.2.2) with 192.168.0.0./16 bridge

Tunnels construct and pass ping to all devices on any subnet in 192.168.0.0…

But, when trying to browse using Port 80 to get to those same devices on their webpages, the connection seems lost, only half constructed. Browse to the Internet is OK but some webpages don’t load all the way.

I have a masquerade rule in , and a hit of myip.dnsomatic.com from 192.168.28.0/24 shows the public address of the head end router…1.1.1.1

html traffic seems to have trouble.


I have used a Cradlepoint MBR-1400 in place of this TIK with the same VPN to the hub, in it’s SOHO “nat mode” with the same 10.10.1.15 wan and tunnels and subnets…and browsing to the interior subnets is flawless.

Just cant seem to get the TIK to do the same…I just know I am missing a rule . the SOHO GUI in the Cradlepoint just does it, use the nat traversal and 10.10.1.15 wan and browsing works.

Please help if you can…

Code of the major fields…if more is needed please ask.

#
Flags: X - disabled, I - invalid, D - dynamic 
 #   ADDRESS            NETWORK         INTERFACE                              
 0   ;;; Public Nat'D
     10.10.1.15/24      10.10.1.0       Eth1-WAN                               
 1   ;;; LAN to VPN Hub
     192.168.28.1/24    192.168.28.0    LAN  Bridge



 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          10.10.1.1                 1
 1 ADC  10.10.1.0/24       10.10.1.15      Eth1-WAN                  0
 2 A S  192.168.0.0/16                     LAN  Bridge               1
 3 ADC  192.168.28.0/24    192.168.28.1    LAN  Bridge               0



#
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=srcnat action=accept src-address=192.168.28.0/24 
     dst-address=192.168.0.0/16 

 1   chain=srcnat action=masquerade src-address=192.168.28.0/24



#
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=input action=accept src-address=192.168.0.0/16 
     dst-address=192.168.28.0/24 

 1   chain=input action=accept connection-state=related 

 2   ;;; NTP SERVER
     chain=input action=accept src-address=66.241.101.63 
     in-interface=Eth1-WAN 

 3   ;;; Hub
     chain=input action=accept src-address=2.2.2.2 in-interface=Eth1-WAN 

 4   ;;; DENY RULE>
!
     chain=input action=drop in-interface=Eth1-WAN



#
Flags: X - disabled 
 0   ;;; HUB
     address=2.2.2.2/32 port=500 auth-method=pre-shared-key 
     secret="test" generate-policy=no exchange-mode=main 
     send-initial-contact=yes nat-traversal=yes my-id-user-fqdn="" 
     proposal-check=obey hash-algorithm=md5 enc-algorithm=3des 
     dh-group=modp768 lifetime=8h lifebytes=0 dpd-interval=30s 
     dpd-maximum-failures=5



#
Flags: X - disabled, D - dynamic, I - inactive 
 0   ;;; HUB
     src-address=192.168.28.0/24 src-port=any dst-address=192.168.0.0/16 
     dst-port=any protocol=all action=encrypt level=require 
     ipsec-protocols=esp tunnel=yes sa-src-address=10.10.1.15 
     sa-dst-address=2.2.2.2 proposal=default priority=0

Browsing problems are often MTU related. Try pinging with longer packet sizes and see what packet size you are actually achieving under each scenario.

I diagram might help to give an overview.