OpenVPN + Juniper

techneitsolutions
techneitsolutions used Ask the Experts™
on
Hi all,

My situation is the following:
I have 2 Juniper SSG5. With an VPN tunnel between them.
intern A: 192.168.1.x
intern B: 192.168.0.x
the tunnel is operational.

I can ping from my OpenVPN server (192.168.1.203 (site A) to the running server at site B (192.168.0.3) (and vice versa).

I now connect my laptop to the OpenVPN server (OpenVPN ip = 10.8.0.1)
My laptop's openvpn ip = 10.8.0.10

I can ping the local recourses on site A (192.168.1.203).
Now, I want to connect to the recourses on site B (192.168.0.3) as well.
but the connection seems not to be able to be established.

Does anyone can help me through here with the configuration on the SSG5? do I need to enable source or dest natting or what do I forget to configure..

thx
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
You use an own network for OpenVPN (which is not necessary anymore with OpenVPN 2.1, but the classic Windows setup).
That network is not known on the other side (B). Just add a route on the B-SSG5 back into the 10.8.0.0/24 network (gateway is OpenVPN server internal address 192.168.1.203)

Author

Commented:
the problem is that I cannot ge outsite the network with my OpenVPN range, so it is a problem on my SSG (site A)
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
Not necessarily. You can solve it on both sides. For side B, you need routing. Otherwise you need NAT-src on side A as soon as you are passing networks. Problem: NAT-src is applied to a tunnel interface OR policy. The latter is appliable only if traffic is passing different zones (Trust to Untrust, for example). I assume the VPN tunnel is trusted, so that option is not available.
If you apply NAT-src on tunnel interface, ALL traffic is NATted, or you have to build a secondary tunnel interface for the OpenVPN addresses. To be honest, I do not know if that is feasible.
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

Author

Commented:
can you explain with an example pls

Author

Commented:
ok, I configured the route on site B and now I can ping to the OpenVPN server (10.8.0.1) but I cannot ping to 10.8.0.6 (my OpenVPN client).

and the client is still not able to connect to the resources, any thoughts?
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
Do you NAT on the OpenVPN server? How come side a knows about the OpenVPN network?

Author

Commented:
ok, let's restart:

I have a machine in my network (192.168.1.203). on this machine I installed OpenVPN with IP 10.8.0.1
I do not have NAT on the OpenVPN server

My client machine is connecting to the openvpn with ip 10.8.0.6

I actualy just find out that I can ping only to 192.168.1.203 and none of the other recourses of site A, my mistake.

I have following zones on the Juniper:
Trust, Untrust, VPNZone

Following interfaces:
Bgroup0 (site A 192.168.1.0/24)                              Site B -> 192.168.0.0/24
Eth1 -> extern inet 192.168.168.x/24
Tunnel.1 -> VPNZone

Untrust to trust -> VIP for port forwarding 1195 for the openvpn connection.

VPNZone to Trust ->
      any -> 192.168.1.0/24
      any -> 10.8.0.0/16
Trust to VPNZone ->
      192.168.1.0/24 -> any
      10.8.0.0/16 -> any

trust to untrust -> any -> any

The tunnel to site B is set up correctly

Can you help me further?
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
That's clear. Your SSGs do not know of the OpenVPN network, as I told you already. The easiest way is to create a route in both SSGs for the OpenVPN network, with the OpenVPN server's internal address as gateway. Since the SSGs are asked for any unknown traffic, they will pass it to the OpenVPN server if it is OpenVPN related.

The "A" SSG need to have the SYN flow control disabled:
unset flow tcp-syn-checkunset flow tcp-syn-bit-check
Else sessions for OpenVPN traffic are not created and traffic dismissed: Because the initial packet usually comes from the OpenVPN client, and addresses the target directly, it will not arrive at SSG, while the response packet has no SYN flag for starting a new session - it expects to use an existing session. It is not that complicated as it sounds. Let's just assume we do not need the SYN flow security feature here.

Site B SSG does not need that setting. All traffic arriving from OpenVPN have passed the SSG in any case, and the session exists already.

Author

Commented:
Hi

I set up the route (already did ;) )

and I performed the commands. but it don't work.

any thoughts?

Author

Commented:
Also, The same configuration on a Fortigate 50B is working without problem.

And when I look into the OpenVPN Log file when connecting through the Fortigate, I get ip adress 192.168.1.1 (the gateway) but when I connect through the juniper, I get the WAN ip from the client laptop.

So the problem is a routing problem I guess on the juniper site? this is why I guess I need to do SNAT on the juniper, so that the packet is routed back to the address it came of.

could that be the issue? can you explain how to configure SNAT?

thx
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
NAT-src would come into play when using traffic between the sites. We are still talking about "local" traffic in site A, don't we?

The difference between FortiGate and Juniper config is obviously that the FortiGate performs NAT on the packet contents (strange and unnecessary), while the Juniper does not (by default). Since the OpenVPN packets arrive at OpenVPN server, this part is confirmed to work in both cases.

Have you setup routing on the OpenVPN Server?

Author

Commented:
Well; I configured following in the config file:

push "route 192.168.1.0 255.255.255.0"
push "route 192.168.0.0 255.255.255.0"

I don't think anything else is configured

but it works on the fortigate, so I find it kind weird that it is not working with juniper
"Batchelor", Developer and EE Topic Advisor
Top Expert 2015
Commented:
That it worked with FortiGate is strange. The only difference is the flow security setting mentioned above.

You can debug on serial console connected to Juniper by issueing
set ff src-ip 10.8.0.6
set ff dst-ip 10.8.0.6
 clear dbuf
debug flow basic
debug flow drop
(vpn traffic here)
undebug all
get dbuf stream

That will show if traffic arrives at SSG, and whether it is discarded.

Author

Commented:
Hi, this is what we get from the logs:

  ipid = 13628(353c), @1d5bd918
  packet passed sanity check.
  bgroup0/0.3:192.168.171.3/768->10.8.0.6/1281,1(0/0)<Root>
  no session found
  flow_first_sanity_check: in <bgroup0/0.3>, out <N/A>
  chose interface bgroup0/0.3 as incoming nat if.
  flow_first_routing: in <bgroup0/0.3>, out <N/A>
  search route to (bgroup0/0.3, 192.168.171.3->10.8.0.6) in vr trust-vr for vsd-
0/flag-0/ifp-null
  [ Dest] 28.route 10.8.0.6->192.168.171.203, to bgroup0/0
  routed (x_dst_ip 10.8.0.6) from bgroup0/0.3 (bgroup0/0.3 in 0) to bgroup0/0
  policy search from zone 2-> zone 2
 policy_flow_search  policy search nat_crt from zone 2-> zone 2
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.8
.0.6, port 19803, proto 1)
  No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 87/0/0x9
  Permitted by policy 87
  No src xlate   choose interface bgroup0/0 as outgoing phy if
  no loop on ifp bgroup0/0.
  session application type 0, name None, nas_id 0, timeout 60sec
  service lookup identified service 0.
  flow_first_final_check: in <bgroup0/0.3>, out <bgroup0/0>
existing vector list 1-b143164.
  Session (id:48028) created for first pak 1
  flow_first_install_session======>
  route to 192.168.171.203
  arp entry found for 192.168.171.203
  ifp2 bgroup0/0, out_ifp bgroup0/0, flag 00800800, tunnel ffffffff, rc 1
  outgoing wing prepared, ready
  handle cleartext reverse route
  search route to (bgroup0/0, 10.8.0.6->192.168.171.3) in vr trust-vr for vsd-0/
flag-3000/ifp-bgroup0/0.3
  [ Dest] 11.route 192.168.171.3->192.168.171.3, to bgroup0/0.3
  route to 192.168.171.3
  arp entry found for 192.168.171.3
  ifp2 bgroup0/0.3, out_ifp bgroup0/0.3, flag 00800805, tunnel ffffffff, rc 1
  flow got session.
  flow session id 48028
  post addr xlation: 192.168.171.3->10.8.0.6.
 flow_send_vector_, vid = 0, is_layer2_if=0
  packet send out to 000c2964c2ff through bgroup0/0

can you help?
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
What are 192.168.171.x for addresses?

Author

Commented:
Qlemo, many thanks on your help with this.

Thanks to the logs I find out that the package was going through a wrong interface. I have 2 interfaces in the zone Trust, there fore, the package was not send correctly through the correct interface which means that the package was dropped (lost actualy)
Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
Looking on the debug output often reveals what is going wrong - but you need to be able to read it. Glad it helped, "and thanks for the fish" (points).

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial