UCM6302a and UCM6304a remote access via VPN

#1

Hello,

I have two UCM devices (6304a and 6302a) across a site to site VPN, with a third L2TP VPN that I use to remote into on demand when I’m working from home. When I remote in, I can access the UCM6302a’s web portal and connect via the Wave app to its extensions. I can not access the UCM6304a, nor can I connect via the Wave app to its extensions. I have a VOIP trunk using the public IP addresses of both UCM devices connecting the two UCM devices together and this works fine for transferring calls back and forth between the two.

The private IP’s ranges of the sites are as follows:

UCM6304a is on 192.168.0.0/24 (Site A)
UCM6302a is on 192.168.1.0/24 (Site B)
I remote in on 192.168.3.0/28 (Site C)

When I (Site C) remote in, I am tunneling into the router on Site A and I can view our file shares and print to printers across both Sites A and B. I have my remote Wave APP connected to the UCM6302a on Site B, but would like to connect instead to the UCM6304a on Site A because it has more analog lines out.

Site C can ping all devices on Site B, including the UCM6302a. Site C can ping all devices on Site A, except UCM6304a.

From within UCM6302a on Site B, I can ping various addresses in Sites A and C, but not the address of the UCM6304a. From the UCM6304a on Site A, I can not ping any address in Sites B or C.

Both UCM devices are current firmware (1.0.19.9).

What I’ve tried, based on other topics I’ve read on this forum:

-> I’ve setup all three networks under the NAT settings of SIP networks on the UCM6304a on Site A. This didn’t work, I was still unable to ping or access the web portal from either Sites B or C.

-> I have verified that both UCM devices are set to switch instead of the default route.

-> On the UCM6304a, I have enabled whitelisting (it was off previously) and listed the entire addressable space from all three networks. This didn’t work either.

-> I turned whitelisting back off on the UCM6304a on Site A and instead tried static routes to Sites B and C. This also did not work.

-> I’ve turned Ping Defense, Syn-Flood Defense, and Ping of Death Defense on and back off again on the UCM6304a. This also didn’t work.

Presently, the only way I have to access the UCM6304a is to RDP to a computer physically at Site A and login locally, or access the UCM6304a from the GDMS Cloud site. At this point, I’m not sure what else I can do. I don’t believe it’s a VPN issue as I can ping, or gain access to network shares, or login to the web portals (when available) from literally all other IP addresses across Sites A and B from Site C, save for the one UCM6304a on Site A.

At this point, I am able to work fully since I can Wave into the UCM on Site B, as stated before, but I sure would like to figure this out and connect to the preferred UCM on Site A. I’m hoping that this is just something very silly that I have completely overlooked and that someone will point it out to me. Thank you for looking!

AP

#2

Dear user,

Thank you for using the UCMRC service and UCM63xx models! May I ask if you can provide the remote access of both UCM63xx models to us for troubleshooting? You can send the admin username/password to us through PM. Thanks for your testing!

Thank you!

#3

L2TP is a VPN mode now considered unsafe,
also UCM630X allows you to use Remote Connect, and use remote offices without having to do any nats.
There are free and paid licenses.

https://www.grandstream.com/products/ucm6300-ecosystem/product/ucm-remoteconnect
https://documentation.grandstream.com/article-categories/ucm6300-ecosystem/

#4

Thanks for your updates, Damiano!

We recommend users to use UCMRC service because it is safe and easy for users without setting up users’ own NATs including building STUN/TURN servers. Thanks for share your comments here.

If the customer has problems about the configuration, the customer can provide the remote access of the UCM63xx to us through private message so that we can check such an issue faster and help the customer to make it work. Thanks!

Thank you!

#5

If you are physically at Site A, can you then ping the 6304 or possibly from the PC at site A that you RDP into?

You did not mention the routers in play at these sites nor what type of VPN is used for the site-site. Are you not able to also remote dial-in with VPN to site A?

#6

Yes, if I’m physically at Site A, or when I RDP into Site A, I can ping the 6304 as well as access the web portal of the device.

When I remote in, I am remoting directly to Site A but am unable to access the 6304 (only, network shares and printers are still available).

The routers are Ultimate Dream Machines from Ubiquity, both running current software. I have a Windows server on Site A I’m using for a print server as well as a network share. I have a LInux server on Site B for a MySQL server. I have printers at both sites that all run through the print server on Site A. Computers from both sites access services successfully, and I can access those same services remotely from Site C.

I hope that adds some clarity!

#7

Thanks!

I have set this up, I should have mentioned that, and can access the preferred UCM on Site A using Remote Connect - however - there is an incredible lag when I’m using the service that doesn’t exist if I go the route of VPN tunneling and connecting to the UCM on Site B (since I can’t tunnel in and connect to the UCM on Site A).

Hope that helps!

#8

or you use the VPN, or you use the Remote Connect,
to begin,
otherwise you don’t understand anything
Choose a road and go on that.

#9

That doesn’t really address the root issue that I can’t access the 6304 on Site A from anything that is not physically on the network at Site A, which is what I’m hoping to work out on this forum.

#10

a solution has been given to you,
see you

Good work

#11

Sorry, but remote connect to the UCM6304a isn’t working as well as a direct VPN connection to the UCM6302a. There is a considerable lag in the voice connection that makes a conversation nearly impossible to carry out and that is why I am keen on figuring out another way.

While I can simply live with the direct VPN connection to the UCM on Site B, it is more desirable to connect to the UCM on Site A as it has more analog outs available.

My question wasn’t about whether or not remote connect would work, or should I use it instead, it was if anyone would know why one UCM doesn’t allow a ping or a web portal connection from anywhere other than a computer physically on the same network as that UCM.

I thank you for your input so far, and hope you can shed some light as to why the UCM6304a is acting the way it is.

Thank you!

#12

It seems like you have a unique situation, since no one has offered a direct solution to you. My suggestion is that you will have to do some work with network packet capturing to trace down what is, and is not, happening.

It sounds to me like there may be a problem with a protocol route between the two sites. A problem with a couple of protocol routes would explain why other network services work between the two sites. You might find that the Ping gets all the way to the other site, and a Pong (the response to a Ping) is issued, but the Pong can’t find it’s way back. That kind of problem can exist in a Router or a Firewall (or maybe even in the VPN).

Best wishes on getting it fixed.
Rick

#13

Thank you, I hadn’t thought about checking the responses. I’ll try this and report back!

#14

Dear user,

Thank you for testing the UCM63xx! This issue should be generated by the VPN environment and deployment, and this is not an issue for UCMRC service. Could you kindly capture a trace file from your UCM63xx and send to us for troubleshooting? Thanks for your testing!

Thank you!

#15

Except that it would need to be a protocol issue tied to an IP as the description provided indicated -
Site C can ping all devices on Site A, except UCM6304a.

The only think I can think of off-hand is if the IP you are pinging from is blacklisted in either Fail2Ban or in Dynamic defense. If it were blacklisted prior to whitelisting, it would still not work until the blacklist entry is removed. I do not know if any attempt was made to RDP into a device at Site B and then see what happens when accessing or pinging the 6304 at A.

As it has been indicated that both UCMs are peered together and working fine, then it should be possible to get into the 6302 and then Maintenance, Network Troubleshooting and then ping from that device to the 6304 as well as use a traceroute from same or even perform one from the remote site. Then by using RDP at Site A and logging into the 6304 using the same tools in reverse to see if the 6304 can see the remote devices and where the route stops (or not).

#16

Dear user,

Thank you for testing the UCM63xx! This issue should be generated by the VPN environment and deployment, and this is not an issue for UCMRC service. Could you kindly capture a trace file from your UCM63xx and send to us for troubleshooting? You can send the trace file to us through a private message. Thanks for your testing!

Thank you!

#17

Thank you, for your response!

This morning, I logged into the UCM6304a on Sie A via RDP to a local computer on Site A and attempted to ping my PC on Site C as well as the UCM6302a on Site B via the ping interface under Network Troubleshooting. Both failed to get any response.

I then tried the same test from with the UCM6302a on Site B, and was able to successfully ping the UCM6304a on Site A as well as my remote IP on Site C.

While I was logged into the UCM6304a, however, I did verify I had Fail2Ban and Dynamic Defense unchecked and they were. But, I did have this enabled when I initially setup and disabled it shortly after as I was having phones drop off the UCM6304a. To be clear, none of that is enabled currently, but do you thing that because it was at one point there could be some lagacy blocking going on under the hood? If so, any ideas how to check for that?

#18

Thank you, I have sent some files off for you to have a look at!

#19

Dear user,

Thank you for your feedback! May I ask if the UCM6304A’s MAC address is XXXXX9154 (IP: 192.168.0.10)? If so, the issue that you cannot ping 192.168.3.1 was caused by ARP no response issue. This issue may be caused by your configuration in your UCM6304A. You can send the SSH with admin password to us through the private message, so that we can log in the UCM6304A remotely to troubleshoot it deeply and resolve it. Thanks for your testing!

Thank you!

#20

Yes, that is the MAC address of the UCM6304a in question. I’ll respond privately with the requested information!

Thank you!