The problem has been resolved, --- There are a couple not-so-obvious issues that I ran into while setting this up, and hopefully I can save someone some bang-head-against-wall moments by posting my working configuration as well as an overview of what was wrong.
First, the obvious, make sure your policies are in the right order, as noted by praveenys
SomeITGuy noted that I needed to use my vlan interface, for whatever reason I thought I had tried that already and it would not let me, but I must not have done it correctly because that did work... Further on that note, there is no issue with running IPSEC VPN over a group of interfaces configured with family ethernet-switching.
Here is a big killer that had me screwed all along:
You can NOT combine multiple subnets into the same policy for a IPSEC-VPN policy... This is something that Junos will let you do, it will pass commit checks, but it does not work, at all. While I understand why this is failing, as proxy-addresses are pulled from this, it would be REALLY NICE if junos was able to handle this a bit better...
In my case, I had the following problem:
I had 3 IP addresses on MY SIDE (ex. 10.1.1.100 - 10.1.1.102) that needed to be allowed on this VPN policy, on the other side I had a total of NINE addresses that needed to be allowed (10.2.1.21 - 10.2.1.25 and 10.3.1.241 -244) , there was no clean-cut subnets available for this. The remote site was NOT able to allow me access to the subnet(s) that could be generated to allow me to access all of those addresses... For this tunnel I HAVE to use /32 addresses.
I was able on my side to allow access to the subnet of 10.1.1.96/29 because I do not have any other equipment that falls into that subnet range... Doing this enabled me to save ALOT of work because for each combination of addresses that you have (remote and local) you have to create a whole new policy. Because I was able to combine mine into a subnet this saved me a TON of work, and I was able to get this VPN tunnel up with only 9 polices.... (which is really stupid crazy compared to what I'm used to with cisco, sorry, have to point that out)
So, I created an address book entry in my trust zone for that subnet 10.1.1.96/29 called Local-10_1_1_96-29
Then I created 9 address book entries for all of the /32 addresses on the remote side using the same type of naming
Then I created 9 policies which all look something like this: (had I not used a subnet on my side, this would be 27 polices!!!)
from-zone trust to-zone untrust {
policy ARIS-1 {
match {
source-address Local-10_1_1_96-29;
destination-address remote_10_1_1_21-32;
application any;
}
then {
permit {
tunnel {
ipsec-vpn remote;
}
}
}
}
}
Once the other side was changed in their configuration to use my local /29 subnet, everything started working.
I have alot of VPNs here that are provided for VENDOR SUPPORT, and these vendors typically have access to only very specific IPs on my network... This is NOT uncommon in my configuration, I don't actually have a single Site to Site VPN setup that allows access to a large subnet... THIS IS A PAIN IN THE A** and I am not looking forward to moving the rest of my VPN tunnels off of Cisco equipment. It would be great to see this made just a little bit easier. JUNOS will allow you to make the policy statement to read something like "source-address [ address-1-32 address-2-32 ] Why the hell can't it figure out that those are all seperate and just deal with it rather than making me put in 9 polices for 1 VPN tunnel which makes looking at my configuration a complete mess?