• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2683
  • Last Modified:

juniper ssg320 intrazone configration issues Close - AGE OUT

We have one main office and another small office that holds only 5 people. We have recently setup OpenVPN on our main office and created a bridged vpn between our main office LAN and a windows 2003 server sitting in the small office. The windows 2003 server has 2 NICs one it uses to interface with the main office which has network /20 and another it uses to talk to the local network on

In the main office we have a juniper SSG320 firewall but in the small office we have no firewall at the moment. The computers in the main office can now ping and access resources on the windows 2003 server in the small office and beyond including resources on the network but when we try the otherway around , computers beyond the windows 2003 server can ping any machine in the main office but if they try to access any shared file in the main office or intranet machine or anything on this network then it fails.

We have looked at the juniper firewall and we have even setup some policies that allow traffic from the other network however, we are getting Close - AGE OUT and Close - RESP on the firewall log.

Any help would be highly appreciated.
  • 4
  • 4
1 Solution
QlemoBatchelor and DeveloperCommented:
The SSG can be kept off the calculation, since you implement a OpenVPN tunnel between the offices. OpenVPN traffic needs to pass the firewall, and that is all it sees. So your issue is more related to the OpenVPN config.

Can you explain why you use two NICs in the branch office? It should work much better if you just use the primary NIC (for the LAN), and nothing else.

Please tell more about your current OpenVPN config. In particular what you mean by "bridged VPN".
aniga42Author Commented:
Qlemo, thank for you response.

Our openVPN config file is :
port 1194
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"
proto udp
dev tap0
ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
push "route"
push "dhcp-option DNS"
push "dhcp-option DOMAIN mclellan.local"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
user nobody
group nogroup
log         /var/log/openvpn/openvpn.log
status /var/log/openvpn-status.log
verb 3

Open in new window

and when I say bridged I mean the computer that is running the openvpn client is bridged to the rest of the network hence why it can get resources (this machine is windows 2003 AD) whereas other machines that are in the other office which connect to this windows 2003 server that is running the client machine cannot get resources from the external network.

Other machines are able to see the extended network through the windows 2003 server which is running a windows routing and remote access to designate the next hop for all packets going to

The connection and the routing seem to be OK as they are able to ping internal computers on the network but when they try to access files our firewall is dropping these connections and this I believe is where the problem lies.

Please see a diagram I quickly drew of our network attached.

Once again, Many thanks for your time and effort

Network design
QlemoBatchelor and DeveloperCommented:
Do you have any proof of "but when they try to access files our firewall is dropping these connections"?
The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

aniga42Author Commented:
Yes, we have a proof on the firewall log, please see attached screenshot
Firewall log
QlemoBatchelor and DeveloperCommented:
What the logs show is related to PING (or DNS), and is a normal close as soon as the response is sent/received. It would have puzzled me if you had seen anything VPN related here.

The OpenVPN config above is for a Linux server ( in your main office.

All in all, your config is kind of complicated. I'm still trying to figure out the details ;-).

I'm assuming you did not set up particular routes on clients in for how to get to, or set them to ask the SSG to route further. The SSG will then route to the OpenVPN server, which again sends traffic to the W2003 server & OpenVPN client. The OpenVPN client will NOT perform address translation. The reply is sent via W2003 -> OpenVPN Server -> LAN, skipping the SSG.
This works because traffic is initiated on the SSG side, creating sessions with the proper flags. It is called asymetric routing, since the packets take a different way for request and reply.

Traffic originating from the branch will not pass the Juniper, only replies will - and exactly that is the issue then. The SSG is receiving reply traffic for sessions it never created, and hence dismisses that. That is a feature to protect from unwanted traffic, and reduce processing time. To switch off that feature, start a telnet against SSG, and issue
  unset flow tcp-syn-check
aniga42Author Commented:
Qlemo: Thank you very much for the info. I fell ill and did not come to the office for a while hence my lack of response.

I have tested the  "unset flow tcp-syn-check" command and it seems to do the trick however after an hour or so this resets itself and I am forced to do the command again manually.

Do you know of any way I can have this traffic trusted permanently?

Many thanks once again.
QlemoBatchelor and DeveloperCommented:
Sounds as if the CLI session is terminated, and the config rolled back. Issue a
after you have changed the setting. That should make it persistent.
aniga42Author Commented:
Thank you very much for your support. I will have that tested.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now