Sorry Pantunes, but you are incorrect. Policy based VPN do NOT require a route to the remote LAN subnet. This is only needed for a route based vpn.
See the Policy based VPN configuration sample
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24 set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30 set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1 set security zones security-zone untrust interfaces ge-0/0/3.0 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone trust interfaces ge-0/0/0.0 set security zones security-zone trust host-inbound-traffic system-services all set security address-book book1 address sunnyvale 10.10.10.0/24 set security address-book book1 attach zone trust set security address-book book2 address chicago 192.168.168.0/24 set security address-book book2 attach zone untrust Read more at http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-policy-based-vpn-configuring.html#wXtlZkUH4YUYKtbW.99
Versus the route based VPN sample
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24 set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30 set interfaces st0 unit 0 family inet address 10.11.11.10/24 set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1 set routing-options static route 192.168.168.0/24 next-hop st0.0 set security zones security-zone untrust interfaces ge-0/0/3.0 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone trust interfaces ge-0/0/0.0 set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone vpn-chicago interfaces st0.0 set security address-book book1 address sunnyvale 10.10.10.0/24 set security address-book book1 attach zone trust set security address-book book2 address chicago 192.168.168.0/24 set security address-book book2 attach zone vpn-chicago Read more at http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-route-based-vpn-configuring.html#gV4QglFl7UWyytGs.99
On this particular case, you can see from the first post that we have valid sessions setup for pings from the SRX to the remote site:
run show security flow session destination-prefix 192.168.75.5/32 Session ID: 10408, Policy name: vpn-1/32, Timeout: 52, Valid In: 192.168.1.190/476 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60 Out: 192.168.75.5/1 --> 192.168.1.190/476;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0 Session ID: 16269, Policy name: vpn-1/32, Timeout: 38, Valid In: 192.168.1.190/473 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60 Out: 192.168.75.5/1 --> 192.168.1.190/473;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0 Session ID: 35130, Policy name: vpn-1/32, Timeout: 58, Valid In: 192.168.1.190/477 --> 192.168.75.5/1;icmp, If: vlan.103, Pkts: 1, Bytes: 60 Out: 192.168.75.5/1 --> 192.168.1.190/477;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
And we have packet counts that encrypt onto the VPN tunnel at the SRX side.
ESP Statistics: Encrypted bytes: 52740 Decrypted bytes: 0 Encrypted packets: 423 Decrypted packets: 0 AH Statistics: Input bytes: 0 Output bytes: 0 Input packets: 0 Output packets: 0 Errors: AH authentication failures: 0, Replay errors: 0 ESP authentication failures: 0, ESP decryption failures: 0 Bad headers: 0, Bad trailers: 0
These are exactly the testing recommended by kb10093 to verify the configurations on the SRX when you have a Policy based VPN that is up but traffic is not passing.
https://kb.juniper.net/InfoCenter/index?page=content&id=KB10093
Further testing needs to be done on the remote side to confirm what happens to those packets sent down the tunnel and why the return traffic is not being sent back to the SRX. These tests verify the the SRX side configuration is correct and working.