I have numerous customers around the world who have Allen Bradley PLC's running our equipment. The PLC's are Ethernet / IP and typically setup with 192.168.1.XXX format. When I am at the office ( or travelling ), I should be able to use Hamachi to get VPN connection to an on-site PC ( that has been done ). Now that I have the connection and permissions, IP of VPN ( customer and my own ), how do I utilize the VPN connection to use the resource of the hardwired E-Net connection to the PLC ? The customer is on local network ( 10.X.X.X ) and I am on another ( 10.X.X.X ). The Hamachi show's we are connected and the IP's of each of us are displayed. The customer can ping the PLC address's but I cannot. We have disabled firewalls. Looking for what may be very simple information. Many posts in other forums about this being done but nothing explaining in detail how to get it up and running ! If I could ping the remote device ( 192.168.1.XXX ), I think I have it from there.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Utilizing VPN for remote PLC programming
- Thread starter yankee101
- Start date
NetworkTek
IS-IT--Management
It sounds as if it is not routing properly. Like mentioned above if your local networks are the same it will not route properly.
Network+ Inet+ MCP MCSA 2k3
Network+ Inet+ MCP MCSA 2k3
It will route properly whether they are the same or not by virtue of them being directly connected (in the same device). The subnets already know about each other no matter what.
Most VPN remote access implementations have the LAN subnet and the vpn pool in different subnets. That way, only the LAN will get NATted out. If they are in the same subnet, you will DEFINITELY have a problem with NAT, as it does not jive with IPSEC---NAT does not work on IPSec packets because when the packet goes through a NAT device, the source address in the packet changes, thereby invalidating the packet.
Two solutions
A.NAT-T...this wraps the IP header into new IP/UDP header (UDP encapsulation)
B.Exclude the VPN pool (set in the VPN server) from NAT rules---this actually sounds like the problem.
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
Most VPN remote access implementations have the LAN subnet and the vpn pool in different subnets. That way, only the LAN will get NATted out. If they are in the same subnet, you will DEFINITELY have a problem with NAT, as it does not jive with IPSEC---NAT does not work on IPSec packets because when the packet goes through a NAT device, the source address in the packet changes, thereby invalidating the packet.
Two solutions
A.NAT-T...this wraps the IP header into new IP/UDP header (UDP encapsulation)
B.Exclude the VPN pool (set in the VPN server) from NAT rules---this actually sounds like the problem.
/
tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!
- Status
Similar threads
- Locked
- Question