11-26-2010 02:30 AM
We have an issue that it seems that every way we turn we are being defeated.
We have a SRX100 in New Zealand, where all DSL connections are apparently PPPoA only (ie no possibility of support of PPPoE). Therefore we need to use a DSL modem in front of the SRX100, to authenticate and connect with PPPoA.
Our issue is that we need to do a site to site IPSec VPN (other side is not Junos) and we can not make NAT Transversal work in lan-to-lan vpn's - as supported by knowledge base articles.
We have spoken with the provider (Xtra) and even though we have a business DSL connection, they don't understand our request for additional routed subnet (which would avoid NAT).
So, in desperation - we decided to try a recommendation of using Half Bridge dsl modem, whereby it uses a type of DHCP spoofing to push the WAN address through to the LAN side - where an interface in DHCP client mode can receive the public IP.
So far so good, however as with PPP type connections, the next hop is actually the public IP. When connected to a Windows XP pc or other devices, this appears to work fine (next hop is the same as the interface ip). However on 10.3R1.9 based JunOS we do see installed routes learned by DHCP (0.0.0.0/0 to 222.111.333.444 via fe-0/0/2.0) whereby the WAN address assigned on fe-0/0/2.0 by DHCP.
Again so far so good, however when one tries to route traffic to the internet via the default route, JunOS returns "no route to host". It seems JunOS does not like having a route to its own interface IP. Next thought was ok - lets put a route with next-hop being the interface (ie
set routing-options static route 0.0.0.0/0 next-hop fe-0/0/2.0
this is accepted, but on commit tells us that the next hop interface can not be a non PPP interface.
On investigation on the half bridge modem (DSL 526B DLink) it shows that the remote gateway is actually in a completely different subnet. Even if i were able to setup a default route to hit that gateway, given its at least a hop away, I have no route to get to that gateway possible.
Please help - am hoping there is a crafty way of getting the routing to work, or someone can suggest another way of avoiding the NAT-T issues we are having on site-to-site IPSec VPN.