MobileVPN Policy settings to allow access to client

4QC_Support4QC_Support
in Firebox - VPN Mobile User

Hi Everyone
I have a Synology NAS behind a T15 FireBox that I am trying to set up a backup to an external NAS (buNAS) using port 22 (SSH Encryption) that is connected by OpenVPN. I have successfully connected the external buNAS to the network (I have also connected my system using the same settings) and confirm it is on the network with the VPN internal address, but I cannot get the internal NAS to 'see' the buNAS (it sort of does, but times out).
I am new so probably missing something - I presume I need to create a policy to do this, but a little unsure how to proceed from this point, any pointers much appreciated! Not using BOVPN, just mobile VPN as the external unit can be shifted from one house to another.
The internal NAS is on 192.168.0.4, the OpenVPN address of the buNAS is 192.168.113.2

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @4QC_Support
    Do you see any deny logs in the traffic monitor for this? That would give us a clue as to what specific policies we need to make.

    -James Carson
    WatchGuard Customer Support

  • 4QC_Support4QC_Support

    Now that is odd. I was going through the traffic logs and could not see any traffic related to the OpenVPN address (192.168.113.2), but could of course see all the encapsulated traffic from the NAS to the external IP of the buNAS (public IP)... I was guessing that the VPN traffic was not being monitored and was going to ask how to do that :)
    In playing around just before posting this, I created a static route in the buNAS via the OpenVPN connection, and promoted the VPN link to the top of the network connections. Went into the HyperBackup on the main NAS, and all of a sudden I am getting a green light, says it can talk to the buNAS now!! I could even browse the backup files. I have the scheduled job to run overnight, I will check back and report tomorrow - fingers crossed! So it must have been the buNAS was not routing back properly - it was visible to the internal network, just not able to reply.

  • 4QC_Support4QC_Support

    Just reporting back that all is good, it was indeed the routing at the client end of the VPN - a good review for anyone in a similar situation :)

Sign In to comment.