Good Evening!
What a ride, but I think I may finally have this sorted. Before I post my spiel let me first say a BIG THANK YOU to everyone who posted here and gave their advice. Without it I would not have gotten as far as I did.
I am posting this in hopes that maybe someone stumbles across this in the future and my pain can ease their configuration woes.
So, what did I do? I wiped the whole thing out is what I did, but you knew that already from my previous post.
After getting back to a pre Dynamic VPN configuration I once again followed this article to attempt the configuration again:
https://www.juniper.net/documentation/en_US/junos12.1/topics/example/vpn-security-dynamic-example-configuring.html
As expected, following that article led me back to the same result of an initial successful connection and a pull of the IKE phase I configuration. Then I was stuck. The client just sits there "Connecting" forever. So I began going back through this thread applying each recommendation and testing again. Let me also say that I removed each one as the connection failed to see if it was a combination of things or one thing in particular that fixed my issue.
set access profile dyn-vpn-access-profile authentication-order password - this made no difference so I removed it.
set security ike gateway dyn-vpn-local-gw dynamic ike-user-type share-ike-id - this one was intersting because I actually inadvertantly used share-ike-id to begin with and when I got to the end I still couldn't connect. Turns out it has to be set to group-ike-id. So this one is a nope.
set security ike gateway dyn-vpn-local-gw dynamic hostname [testhostname] - confirmed that no matter what hostname I gave it it never made a difference in connection.
set security ike gateway dyn-vpn-local-gw local-address <Public VPN IP Address> - and now we get to the resolution of the issue. I can only assume that since I have 3 different IP addresses on a single interface the firewall has to be told which address to be used for the ike gateway. Sure enough after lots of sets/deletes this is the only configuration change that made a difference.
Why things were acting weird Friday I don't know, but I have been testing all night and no matter what I do I see my changes represented when I connect to the Pulse client now. So, so far <knock on wood>, so good.
Because this configuration was relatively basic I wanted to expand on this post with some additional information/questions for the community.
From my understading the configuration linked above is a split tunnel configuration which, depending on your situation, may be a no no. As I read it you are only tunneling to the protected networks defined in remote-protected-resources and everything else uses the user's internet connection. I wanted 0.0.0.0/0 protected, but this was far easier said than done. You can put 0.0.0.0/0 but you aren't going to get very far if you want your users to be able to continue to use the internet while they are connected to your VPN. I dunno, typing that, maybe you do want that and you can simply stop there. For me though, I want users to still be able to connect to the internet to do their job.
That's where this video (https://www.youtube.com/watch?v=J1C4300zMBU) and my questions come into play.
Basically, am I correct with the following configurations?
- Security policies for untrust to untrust to permit any source\destination\application
- Source nat from zone untrust to zone untrust match 0.0.0.0/0 then source-nat interface
While this appears to have the result I am looking for I would just like confirmation that this is the proper configuration.
It wouldn't much do to try to secure the VPN only to open a hole somewhere else.
I apologize for the wall-o-text, but there was a lot going on here and if nothing else I hope this helps someone out down the road.
I know it was a lot, but if someone wouldn't mind confirming the above question or recommending a different configuration I would really appreciate it!
Thanks for reading,
Michael