CA2471283A1 - Initiating connections through firewalls and network address translators - Google Patents
Initiating connections through firewalls and network address translators Download PDFInfo
- Publication number
- CA2471283A1 CA2471283A1 CA002471283A CA2471283A CA2471283A1 CA 2471283 A1 CA2471283 A1 CA 2471283A1 CA 002471283 A CA002471283 A CA 002471283A CA 2471283 A CA2471283 A CA 2471283A CA 2471283 A1 CA2471283 A1 CA 2471283A1
- Authority
- CA
- Canada
- Prior art keywords
- communications
- address
- virtual pipe
- access
- pipe
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2578—NAT traversal without involvement of the NAT server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
Abstract
Access to private devices (220) that are separated from the public network by firewalls (222) and network address translators (NATs) is provided without reconfiguring the firewalls and NATs. A private device wishing to provide access to external devices (240) establishes a virtual private pipe (226) to a secure hub (200), which includes functionality to terminate virtual pipes and to switch communications between these pipes and the public network (112). The secure hub assigns a secondary IP address to the private device/pipe and thereby provides the private device with a network appearance that is now beyond the firewall/NAT. External devices access the private device by addressing communications to the secondary IP address, which communications are routed to the secure hub and tunneled through the pipe to the private device. The private device can also restrict access through an access control list that is enforced by the secure hub.
Description
INITIATING CONNECTIONS THROUGH FIREWALLS AND NETWORK
ADDRESS TRANSLATORS
BACKGROUND OF OUR INVENTION
FIELD OF THE INVENTION
Our invention relates generally to communicating through firewalls and network address translators (NAT). More particularly, our invention relates to switching system apparatus~for enabling external devices to communicate with private devices located behind firewalls and NATs by way of virtual private pipes.
io DESCRIPTION OF THE BACKGROUND
It is common for both corporations and home users to place firewalls and/or network address translators (NAT) between their local private networks and the public network. As is known, firewalls address security concerns, enforcing is access control policies that regulate the types of traffic that can be sent from the local network to the public network and, perhaps more importantly, the types of traffic that can access the local network from the public network. In addition to providing some degree of security, NATs are primarily directed at IP-address scarcity and allow a set of devices on a private network to use a single IP
address 2o to interface the public network. Although differing applications, these two technologies pose a similar problem - they make it difficult for two devices (e.g., corporate/personal computers, servers, network appliances, etc.) separated by one 'or more firewalls/NATs to openly communicate.
For example, device 106 of Figure 1 resides on a public network, device 2s 102 resides on private home network that is separated from the public network 112 by a NAT 104, and device 110 resides on a private corporate network that is separated from the public network by a firewall 108. Assuming firewall 108 allows external communications, devices 102 and 110 can initiate communications with device 106. However, device 106 cannot easily initiate communications with 3o either of devices 102 or 110 unless firewall 108 is first reconfigured to allow device 106 access, or a forwarding is first configured on NAT 104. The situation becomes somewhat worse if devices 102 and 110 wish to communicate because neither can initiate communications unless the firewall and/or NAT are first reconfigured.
Reconfiguration of firewalls and NATs is not a workable solution to the above described communications problem for several reasons. First, reconfiguration is an administrative process, which for firewalls is slow because it often requires corporate approval, and for NATs is difficult because it requires an understanding of IP, which many users do not possess. Second, the number of required reconfigurations rapidly increases as the number of devices seeking access across a firewall or NAT increases. For example, every desired peer-to-peer connection requires a separate reconfiguration. Third, security risks increase as firewalls and NATs are increasingly opened to public access.
SUMMARY OF OUR INVENTION
Accordingly, it is desirable to provide methods and apparatus that allow devices separated by firewalls and NATs to communicate without reconfiguring the firewalls and NATs and without decreasing security, thereby overcoming the is above and other disadvantages of the prior art. Under our invention, a secure hub is located in the public network and provides functionality to terminate virtual private pipes and functionality to switch communications between the public network and established virtual private pipes.
In accordance with a first embodiment of our invention, a private device 2o that is separated from the public network by a firewall or NAT and that wishes to provide access to external devices establishes a virtual private pipe to the secure hub. The secure hub assigns and associates~a secondary public IP address to the private device/pipe. To applications residing on the device, the virtual pipe and IP address are a new interface through which communications to external devices 2s can be established. More importantly, the secure hub and virtual pipe provide the private device with a network appearance that is beyond the firewall/NAT.
Hence, an external device can access the private device by addressing communications using the secondary IP address. These communications are routed to the secure hub, which associates the IP address with the pipe and tunnels the 3o communications to the private device.
In accordance with a second embodiment of our invention, the private device provides restricted access to external devices. Here, the secure hub establishes an access control list for the private device in addition to establishing the virtual pipe as described above. To gain access to the private device, it is preferred that an external device also first establishes a virtual pipe to the secure hub. As part of the establishment procedures, the secure hub uses the access control list to determine whether the external device has permission to access the private device. Similarly, the secure hub can determine if access is granted at the time communications addressed to the private device are received from the external device. Assuming access is granted, communications are tunneled from the external device to the secure hub, which then routes and tunnels the communications to the private device. Uniquely, our invention allows a private io device to provide secure access to external devices without having to reconfigure the firewall/NAT.
BRIEF DESCRIPTION OF THE DRAWINGS
is Figure 1 depicts a prior art architecture where NATs and firewalls separate private home and corporate devices from the public network.
Figure 2 depicts a first illustrative embodiment of our invention where a private device creates a secure virtual private pipe to a secure hub that then assigns and associates a public IP address to the private device/virtual pipe and Zo thereby provides the private device with an appearance on the public network that can be accessed by external devices.
Figure 3 depicts a second illustrative embodiment of our invention where a private device creates a secure virtual private pipe to a secure hub that also enforces restricted access to the private device and as a result, external devices 2s also establish a secure virtual private pipe to the secure hub prior to being able to access the private device.
DETAILED DESCRIPTION OF OUR INVENTION
Figure 2 shows a block diagram of secure hub 200 of our invention that 3o allows devices outside a firewall/NAT (hereinafter, firewall will be used to collectively refer to a firewall, NAT, or other device or apparatus that similarly blocks access) to initiate communications with and gain secure access to devices behind a firewall without requiring reconfiguration of that firewall. Secure hub 200 is a switching system that resides on the public network 112 outside any firewalls.
The secure hub's purpose is to allow a private device 220 behind a firewall 222 to create a network appearance on the public network to which other devices can address communications and thereby initiate communications with/access the secure device without having to address the issues posed by the firewall.
Secure hub 200 comprises one or more network interfaces 206 and routing/switching functionality 202 that allows it to switch data among these interfaces. Additionally, secure hub 200 comprises "virtual private network"/"pipe termination" functionality 204 that, combined with its switching capabilities, allows to it to switch data among terminated virtual pipes and the network interfaces.
Through these capabilities, a private device 220 can allow external devices, such as devices 240 and 242, to initiate communications. Specifically, private device 220 first establishes a virtual private pipe 226 over its network interface 224 and through its firewall 222 to secure hub 200. The secure hub then assigns, from an is available IP address pool 212 assigned to~the hub for example, a secondary IP
address 230 to the private device and associates this address with the pipe.
As is further described below, address 230 may be a public address or a private address with restricted access. To applications residing on device 220, virtual pipe 226 and IP address 230 are a new interface through which communications 228 2o to external devices can be established. For example, an application can originate communications using IP address 230, which communications are tunneled over the pipe to the secure hub and then routed over one of the hub's network interfaces 206 to the public network 112.
More importantly, the secure hub and virtual pipe 226 provide private 2s device 220 with a network appearance that is beyond the firewall 222 and directly accessible by external devices. For example, assuming the IP address 230 is a public address, external devices 240 and 242 can address communications to this address and thereby access the private device by way of the secure hub.
Communications so addressed will be routed to the secure hub, which will then 3o associate the IP address 230 with the pipe 226 and route/tunnel the communications (228) over the pipe and through the firewall to the private device.
The advantage of our invention is that by establishing a virtual pipe to secure hub 200, a private device can provide secure access to external devices without having to reconfigure the firewall.
The virtual pipe 226 can be established at the request of a user or at system startup, etc. The pipe can be implemented through such protocols as the s Point-to-Point Tunnel Protocol (PPTP) or the Layer 2 Tunnel Protocol (L2TP), although our invention is not specific to the exact tunneling protocol. For security purposes, communications 228 tunneled through the pipe can be encrypted and the pipe can be configured at the private device with onward routing disallowed to ensure the pipe identifies a specific private device (or even a user on that device) to and not any device located on a private network. In addition, the secure hub can maintain a list of users who have authorization to establish a pipe and can authenticate a secure device against this list when a pipe is established.
As part of the virtual pipe establishment procedures, the secure hub will assign the private device an IP address 230, as indicated above, and may also is negotiate an access control list 210 with the private device. As one option, the private device 220 may decide to allow access to any external device. In this case, the access control list 210 is not required and a public IP address must be assigned to the pipe. As such, the secure hub will obtain an available public IP
address from the available IP address pool 212, configure its routing tables 2o such that the IP address 230 is associated with the pipe, notify the secure device of this address so that it may be used by applications, and update a public domain name system (DNS) server 244, for example, to allow external devices to find the secure device. Under this scenario, any external device can access the secure device by addressing all communications to this public address. The public 2s network will route the communications to the secure hub and the secure hub will subsequently associate the address with the pipe and tunnel the communications to the private device. Once the private device has completed using the pipe, it will close the pipe and the secure hub will reallocate the IP address to the pool 212.
Optionally, the secure hub may only allow the pipe to stay active for a predefined 3o duration and, at the end of this duration, automatically close the pipe and reallocate the IP address.
As a second option, the private device 220 may decide to restrict access to a specific set of external devices, as shown in Figure 3. In this case, the secure hub not only acts as a switching system, switching communications to and from the virtual pipe 226, but also provides network security, selectively determining which external devices should have access to the private device. As such, the secure hub must establish and configure the access control list 210 for the private device. The access control list specifies, for example, a list of external devices or user IDs and can be established in various ways, although none is specific to our invention. For example, using a Web-based or similar interface over a connection through the virtual pipe 226, the secure hub 200 can query private device 220 for the access control information. To facilitate the implementation of selective io access, it is preferred that the secure hub assigns a private IP address from the address pool 212 to the private device 220 in this case, although nothing precludes the use of a public address. Finally, the secure hub configures its routing tables 208 such that the IP address is associated with the virtual pipe 226, notifies the private device of the secondary address, and updates a private DNS
is server 246, for example, to allow external devices to find the private device.
To gain access to the private device 220 in this second scenario, it is preferred that an external device 240 or 242 first creates a virtual pipe 244 or 246, respectively, to secure hub 200 as described above. Again, to facilitate the implementation of selective access, a private IP address should also be assigned 2o to the external device, although nothing precludes the use of a public address. As one option, the external device will specify to the secure hub a desire to communicate with the private device 220 as part of the pipe establishment and authentication procedures. In response to this request, the secure hub will verify that the external device is on the private device's access control list 210 and, if so, 2s will register an indication that future communications from this device can be routed to the private device over pipe 226. Similarly, the secure hub can determine whether the external device has access to the private device at the time communications addressed to the private device are received from the external device.
so Similar to above, once the secure hub has configured the virtual pipe 244 or 246 associated with the external device 240 or 242, applications on the external devices can learn of the IP address 232 associated with the private device 220 through the private DNS server 246, for example. Subsequent communications from the external device 240 or 244 addressed to the private device 220 will then be tunneled over the secure pipe 244 or 246 to the secure hub, which will then associate the IP address 232 with virtual pipe 226 and tunnel the communications to the private device 220. Once the private device 220 has completed using the s pipe, it will close the pipe and the secure hub will reallocate the IP
address 232 to the pool 212. Optionally, the secure hub may only allow the pipe to stay active for a predefined duration and, at the end of this duration, automatically close the pipe and reallocate the IP address.
The above-described embodiments of our invention are intended to be to illustrative only. Numerous other embodiments may be devised by those skilled in the art without departing from the spirit and scope of our invention.
ADDRESS TRANSLATORS
BACKGROUND OF OUR INVENTION
FIELD OF THE INVENTION
Our invention relates generally to communicating through firewalls and network address translators (NAT). More particularly, our invention relates to switching system apparatus~for enabling external devices to communicate with private devices located behind firewalls and NATs by way of virtual private pipes.
io DESCRIPTION OF THE BACKGROUND
It is common for both corporations and home users to place firewalls and/or network address translators (NAT) between their local private networks and the public network. As is known, firewalls address security concerns, enforcing is access control policies that regulate the types of traffic that can be sent from the local network to the public network and, perhaps more importantly, the types of traffic that can access the local network from the public network. In addition to providing some degree of security, NATs are primarily directed at IP-address scarcity and allow a set of devices on a private network to use a single IP
address 2o to interface the public network. Although differing applications, these two technologies pose a similar problem - they make it difficult for two devices (e.g., corporate/personal computers, servers, network appliances, etc.) separated by one 'or more firewalls/NATs to openly communicate.
For example, device 106 of Figure 1 resides on a public network, device 2s 102 resides on private home network that is separated from the public network 112 by a NAT 104, and device 110 resides on a private corporate network that is separated from the public network by a firewall 108. Assuming firewall 108 allows external communications, devices 102 and 110 can initiate communications with device 106. However, device 106 cannot easily initiate communications with 3o either of devices 102 or 110 unless firewall 108 is first reconfigured to allow device 106 access, or a forwarding is first configured on NAT 104. The situation becomes somewhat worse if devices 102 and 110 wish to communicate because neither can initiate communications unless the firewall and/or NAT are first reconfigured.
Reconfiguration of firewalls and NATs is not a workable solution to the above described communications problem for several reasons. First, reconfiguration is an administrative process, which for firewalls is slow because it often requires corporate approval, and for NATs is difficult because it requires an understanding of IP, which many users do not possess. Second, the number of required reconfigurations rapidly increases as the number of devices seeking access across a firewall or NAT increases. For example, every desired peer-to-peer connection requires a separate reconfiguration. Third, security risks increase as firewalls and NATs are increasingly opened to public access.
SUMMARY OF OUR INVENTION
Accordingly, it is desirable to provide methods and apparatus that allow devices separated by firewalls and NATs to communicate without reconfiguring the firewalls and NATs and without decreasing security, thereby overcoming the is above and other disadvantages of the prior art. Under our invention, a secure hub is located in the public network and provides functionality to terminate virtual private pipes and functionality to switch communications between the public network and established virtual private pipes.
In accordance with a first embodiment of our invention, a private device 2o that is separated from the public network by a firewall or NAT and that wishes to provide access to external devices establishes a virtual private pipe to the secure hub. The secure hub assigns and associates~a secondary public IP address to the private device/pipe. To applications residing on the device, the virtual pipe and IP address are a new interface through which communications to external devices 2s can be established. More importantly, the secure hub and virtual pipe provide the private device with a network appearance that is beyond the firewall/NAT.
Hence, an external device can access the private device by addressing communications using the secondary IP address. These communications are routed to the secure hub, which associates the IP address with the pipe and tunnels the 3o communications to the private device.
In accordance with a second embodiment of our invention, the private device provides restricted access to external devices. Here, the secure hub establishes an access control list for the private device in addition to establishing the virtual pipe as described above. To gain access to the private device, it is preferred that an external device also first establishes a virtual pipe to the secure hub. As part of the establishment procedures, the secure hub uses the access control list to determine whether the external device has permission to access the private device. Similarly, the secure hub can determine if access is granted at the time communications addressed to the private device are received from the external device. Assuming access is granted, communications are tunneled from the external device to the secure hub, which then routes and tunnels the communications to the private device. Uniquely, our invention allows a private io device to provide secure access to external devices without having to reconfigure the firewall/NAT.
BRIEF DESCRIPTION OF THE DRAWINGS
is Figure 1 depicts a prior art architecture where NATs and firewalls separate private home and corporate devices from the public network.
Figure 2 depicts a first illustrative embodiment of our invention where a private device creates a secure virtual private pipe to a secure hub that then assigns and associates a public IP address to the private device/virtual pipe and Zo thereby provides the private device with an appearance on the public network that can be accessed by external devices.
Figure 3 depicts a second illustrative embodiment of our invention where a private device creates a secure virtual private pipe to a secure hub that also enforces restricted access to the private device and as a result, external devices 2s also establish a secure virtual private pipe to the secure hub prior to being able to access the private device.
DETAILED DESCRIPTION OF OUR INVENTION
Figure 2 shows a block diagram of secure hub 200 of our invention that 3o allows devices outside a firewall/NAT (hereinafter, firewall will be used to collectively refer to a firewall, NAT, or other device or apparatus that similarly blocks access) to initiate communications with and gain secure access to devices behind a firewall without requiring reconfiguration of that firewall. Secure hub 200 is a switching system that resides on the public network 112 outside any firewalls.
The secure hub's purpose is to allow a private device 220 behind a firewall 222 to create a network appearance on the public network to which other devices can address communications and thereby initiate communications with/access the secure device without having to address the issues posed by the firewall.
Secure hub 200 comprises one or more network interfaces 206 and routing/switching functionality 202 that allows it to switch data among these interfaces. Additionally, secure hub 200 comprises "virtual private network"/"pipe termination" functionality 204 that, combined with its switching capabilities, allows to it to switch data among terminated virtual pipes and the network interfaces.
Through these capabilities, a private device 220 can allow external devices, such as devices 240 and 242, to initiate communications. Specifically, private device 220 first establishes a virtual private pipe 226 over its network interface 224 and through its firewall 222 to secure hub 200. The secure hub then assigns, from an is available IP address pool 212 assigned to~the hub for example, a secondary IP
address 230 to the private device and associates this address with the pipe.
As is further described below, address 230 may be a public address or a private address with restricted access. To applications residing on device 220, virtual pipe 226 and IP address 230 are a new interface through which communications 228 2o to external devices can be established. For example, an application can originate communications using IP address 230, which communications are tunneled over the pipe to the secure hub and then routed over one of the hub's network interfaces 206 to the public network 112.
More importantly, the secure hub and virtual pipe 226 provide private 2s device 220 with a network appearance that is beyond the firewall 222 and directly accessible by external devices. For example, assuming the IP address 230 is a public address, external devices 240 and 242 can address communications to this address and thereby access the private device by way of the secure hub.
Communications so addressed will be routed to the secure hub, which will then 3o associate the IP address 230 with the pipe 226 and route/tunnel the communications (228) over the pipe and through the firewall to the private device.
The advantage of our invention is that by establishing a virtual pipe to secure hub 200, a private device can provide secure access to external devices without having to reconfigure the firewall.
The virtual pipe 226 can be established at the request of a user or at system startup, etc. The pipe can be implemented through such protocols as the s Point-to-Point Tunnel Protocol (PPTP) or the Layer 2 Tunnel Protocol (L2TP), although our invention is not specific to the exact tunneling protocol. For security purposes, communications 228 tunneled through the pipe can be encrypted and the pipe can be configured at the private device with onward routing disallowed to ensure the pipe identifies a specific private device (or even a user on that device) to and not any device located on a private network. In addition, the secure hub can maintain a list of users who have authorization to establish a pipe and can authenticate a secure device against this list when a pipe is established.
As part of the virtual pipe establishment procedures, the secure hub will assign the private device an IP address 230, as indicated above, and may also is negotiate an access control list 210 with the private device. As one option, the private device 220 may decide to allow access to any external device. In this case, the access control list 210 is not required and a public IP address must be assigned to the pipe. As such, the secure hub will obtain an available public IP
address from the available IP address pool 212, configure its routing tables 2o such that the IP address 230 is associated with the pipe, notify the secure device of this address so that it may be used by applications, and update a public domain name system (DNS) server 244, for example, to allow external devices to find the secure device. Under this scenario, any external device can access the secure device by addressing all communications to this public address. The public 2s network will route the communications to the secure hub and the secure hub will subsequently associate the address with the pipe and tunnel the communications to the private device. Once the private device has completed using the pipe, it will close the pipe and the secure hub will reallocate the IP address to the pool 212.
Optionally, the secure hub may only allow the pipe to stay active for a predefined 3o duration and, at the end of this duration, automatically close the pipe and reallocate the IP address.
As a second option, the private device 220 may decide to restrict access to a specific set of external devices, as shown in Figure 3. In this case, the secure hub not only acts as a switching system, switching communications to and from the virtual pipe 226, but also provides network security, selectively determining which external devices should have access to the private device. As such, the secure hub must establish and configure the access control list 210 for the private device. The access control list specifies, for example, a list of external devices or user IDs and can be established in various ways, although none is specific to our invention. For example, using a Web-based or similar interface over a connection through the virtual pipe 226, the secure hub 200 can query private device 220 for the access control information. To facilitate the implementation of selective io access, it is preferred that the secure hub assigns a private IP address from the address pool 212 to the private device 220 in this case, although nothing precludes the use of a public address. Finally, the secure hub configures its routing tables 208 such that the IP address is associated with the virtual pipe 226, notifies the private device of the secondary address, and updates a private DNS
is server 246, for example, to allow external devices to find the private device.
To gain access to the private device 220 in this second scenario, it is preferred that an external device 240 or 242 first creates a virtual pipe 244 or 246, respectively, to secure hub 200 as described above. Again, to facilitate the implementation of selective access, a private IP address should also be assigned 2o to the external device, although nothing precludes the use of a public address. As one option, the external device will specify to the secure hub a desire to communicate with the private device 220 as part of the pipe establishment and authentication procedures. In response to this request, the secure hub will verify that the external device is on the private device's access control list 210 and, if so, 2s will register an indication that future communications from this device can be routed to the private device over pipe 226. Similarly, the secure hub can determine whether the external device has access to the private device at the time communications addressed to the private device are received from the external device.
so Similar to above, once the secure hub has configured the virtual pipe 244 or 246 associated with the external device 240 or 242, applications on the external devices can learn of the IP address 232 associated with the private device 220 through the private DNS server 246, for example. Subsequent communications from the external device 240 or 244 addressed to the private device 220 will then be tunneled over the secure pipe 244 or 246 to the secure hub, which will then associate the IP address 232 with virtual pipe 226 and tunnel the communications to the private device 220. Once the private device 220 has completed using the s pipe, it will close the pipe and the secure hub will reallocate the IP
address 232 to the pool 212. Optionally, the secure hub may only allow the pipe to stay active for a predefined duration and, at the end of this duration, automatically close the pipe and reallocate the IP address.
The above-described embodiments of our invention are intended to be to illustrative only. Numerous other embodiments may be devised by those skilled in the art without departing from the spirit and scope of our invention.
Claims (15)
1. A method performed by a hub for enabling a first device to allow communications from a second device wherein the first device is separated from the second device by access blocking apparatus, said method comprising:
terminating a virtual pipe from the first device, assigning an IP address to the first device and associating this IP address with the virtual pipe, receiving communications originated by the second device and addressed to said IP address, routing the communications addressed to said IP address to the virtual pipe, and tunneling the communications over the virtual pipe to the first device.
terminating a virtual pipe from the first device, assigning an IP address to the first device and associating this IP address with the virtual pipe, receiving communications originated by the second device and addressed to said IP address, routing the communications addressed to said IP address to the virtual pipe, and tunneling the communications over the virtual pipe to the first device.
2. The method of claim 1 further comprising the steps of:
receiving second communications originated by the first device through the virtual pipe, and routing the second communications from the first device to the second device.
receiving second communications originated by the first device through the virtual pipe, and routing the second communications from the first device to the second device.
3. The method of claim 1 further comprising the step of:
encrypting the communications prior to tunneling the communications over the virtual pipe.
encrypting the communications prior to tunneling the communications over the virtual pipe.
4. The method of claim 1 further comprising the steps of:
receiving a plurality of communications originated by a plurality of second devices and addressed to the IP address, routing the plurality of communications addressed to the IP address to the virtual pipe, and tunneling the plurality of communications over the virtual pipe to the first device.
receiving a plurality of communications originated by a plurality of second devices and addressed to the IP address, routing the plurality of communications addressed to the IP address to the virtual pipe, and tunneling the plurality of communications over the virtual pipe to the first device.
5. The method of claim 1 further comprising the steps of:
establishing an access control list to control access to the first device, and based on the access control list, routing the communications from the second device to the first device only if the second device has permission to access the first device.
establishing an access control list to control access to the first device, and based on the access control list, routing the communications from the second device to the first device only if the second device has permission to access the first device.
6. The method of claim 1 further comprising the steps of:
terminating a second virtual pipe from the second device, assigning a second IP address to the second device, and receiving the communications from the second device through the second virtual pipe.
terminating a second virtual pipe from the second device, assigning a second IP address to the second device, and receiving the communications from the second device through the second virtual pipe.
7. The method of claim 6 wherein the IP addresses assigned to the first and second devices are private IP addresses.
8. A system for enabling communications between a first device and a second device wherein said first device is separated from said second device by access blocking apparatus, said system comprising:
a secure hub, and a virtual pipe between the first device and said secure hub, said secure hub including a pool of available IP addresses from which an IP address can be assigned to the first device, means for associating the assigned IP address with the virtual pipe, means for routing communications from the second device and addressed to the first device to the virtual pipe, and means for tunneling said communications over the virtual pipe to the first device.
a secure hub, and a virtual pipe between the first device and said secure hub, said secure hub including a pool of available IP addresses from which an IP address can be assigned to the first device, means for associating the assigned IP address with the virtual pipe, means for routing communications from the second device and addressed to the first device to the virtual pipe, and means for tunneling said communications over the virtual pipe to the first device.
9. The system of claim 8 wherein said means for tunneling tunnels second communications over the virtual pipe from the first device, and wherein said means for routing routes the second communications to the second device.
10. The system of claim 8 further comprising:
a virtual pipe between the second device and said secure hub, and wherein said means for associating associates a second IP address from the pool of available IP addresses with the second virtual pipe, and wherein said means for tunneling tunnels said communications from the second device through the second virtual pipe.
a virtual pipe between the second device and said secure hub, and wherein said means for associating associates a second IP address from the pool of available IP addresses with the second virtual pipe, and wherein said means for tunneling tunnels said communications from the second device through the second virtual pipe.
11. The system of claim 8 further comprising:
an access control list to control access to the first device, and wherein, based on the access control list, said means for routing the communications from the second device to the first device routes the communications only if the second device has permission to access the first device.
an access control list to control access to the first device, and wherein, based on the access control list, said means for routing the communications from the second device to the first device routes the communications only if the second device has permission to access the first device.
12. A system for enabling communication to a first communication device through the public network from a second communication device, said first and second communication devices being separated by at least one security access blocking apparatus, said system comprising a secure hub having routing and switching functionality and pipe termination functionality and having interfaces to said public network, and means for creating a virtual pipe between said secure hub and said first communication device for tunneling communication, said secure hub further including means for assigning an IP address to said first communication device and associating said IP address with said virtual pipe.
13. The system of claim 12 further including means for establishing said communication from said second communication device through said public network to said secure hub.
14. The system of claim 13 wherein said means for establishing said communication from said second communication device includes means for defining a second virtual pipe.
15. The system of claim 12 wherein said secure hub includes means for defining an access control list, said routing and switching functionality routing said communication from said second communication device to said virtual pipe only if such access is permitted by said access control list.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/052,094 US20030140142A1 (en) | 2002-01-18 | 2002-01-18 | Initiating connections through firewalls and network address translators |
| US10/052,094 | 2002-01-18 | ||
| PCT/US2003/001188 WO2003069493A1 (en) | 2002-01-18 | 2003-01-15 | Initiating connections through firewalls and network address translators |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2471283A1 true CA2471283A1 (en) | 2003-08-21 |
Family
ID=21975426
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002471283A Abandoned CA2471283A1 (en) | 2002-01-18 | 2003-01-15 | Initiating connections through firewalls and network address translators |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20030140142A1 (en) |
| EP (1) | EP1466262A1 (en) |
| JP (1) | JP2005518117A (en) |
| CA (1) | CA2471283A1 (en) |
| WO (1) | WO2003069493A1 (en) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6665702B1 (en) | 1998-07-15 | 2003-12-16 | Radware Ltd. | Load balancing |
| GB2362482A (en) * | 2000-05-15 | 2001-11-21 | Ridgeway Systems & Software Lt | Direct slave addressing to indirect slave addressing |
| GB2365256A (en) | 2000-07-28 | 2002-02-13 | Ridgeway Systems & Software Lt | Audio-video telephony with port address translation |
| GB2369746A (en) * | 2000-11-30 | 2002-06-05 | Ridgeway Systems & Software Lt | Communications system with network address translation |
| US7107613B1 (en) * | 2002-03-27 | 2006-09-12 | Cisco Technology, Inc. | Method and apparatus for reducing the number of tunnels used to implement a security policy on a network |
| US9497168B2 (en) * | 2002-07-30 | 2016-11-15 | Avaya Inc. | Method and apparatus for supporting communications between a computing device within a network and an external computing device |
| AU2003276869A1 (en) * | 2002-09-09 | 2004-03-29 | Netrake Corporation | System for allowing network traffic through firewalls |
| US8327436B2 (en) * | 2002-10-25 | 2012-12-04 | Randle William M | Infrastructure architecture for secure network management with peer to peer functionality |
| WO2004063843A2 (en) * | 2003-01-15 | 2004-07-29 | Matsushita Electric Industrial Co., Ltd. | PEER-TO-PEER (P2P) CONNECTION DESPITE NETWORK ADDRESS TRANSLATOR (NATs) AT BOTH ENDS |
| US7899932B2 (en) * | 2003-01-15 | 2011-03-01 | Panasonic Corporation | Relayed network address translator (NAT) traversal |
| US7844731B1 (en) * | 2003-11-14 | 2010-11-30 | Symantec Corporation | Systems and methods for address spacing in a firewall cluster |
| CN100414938C (en) * | 2004-01-05 | 2008-08-27 | 华为技术有限公司 | Network safety system and method |
| EP1699185A1 (en) * | 2004-01-30 | 2006-09-06 | Matsushita Electric Industries Co., Ltd. | Communication system, information processing system, information processing apparatus, tunnel management apparatus, information processing method, tunnel management method, and program |
| US8126999B2 (en) | 2004-02-06 | 2012-02-28 | Microsoft Corporation | Network DNA |
| ATE347774T1 (en) * | 2004-10-04 | 2006-12-15 | Cit Alcatel | DEVICES AND METHOD FOR RUNNING BIDIRECTIONAL CONNECTIONS OVER AN INTERMEDIATE FIREWALL WITH ADDRESS TRANSFORMATION DEVICE |
| US7948890B2 (en) | 2004-12-14 | 2011-05-24 | Industrial Technology Research Institute | System and method for providing a communication channel |
| US7823196B1 (en) | 2005-02-03 | 2010-10-26 | Sonicwall, Inc. | Method and an apparatus to perform dynamic secure re-routing of data flows for public services |
| GB2431067B (en) | 2005-10-07 | 2008-05-07 | Cramer Systems Ltd | Telecommunications service management |
| GB2432992B (en) * | 2005-11-18 | 2008-09-10 | Cramer Systems Ltd | Network planning |
| GB2433675B (en) * | 2005-12-22 | 2008-05-07 | Cramer Systems Ltd | Communications circuit design |
| US7903585B2 (en) * | 2006-02-15 | 2011-03-08 | Cisco Technology, Inc. | Topology discovery of a private network |
| WO2007094059A1 (en) * | 2006-02-15 | 2007-08-23 | R & W, Inc. | Data transmitting and receiving method |
| GB2435362B (en) * | 2006-02-20 | 2008-11-26 | Cramer Systems Ltd | Method of configuring devices in a telecommunications network |
| US9021134B1 (en) * | 2006-03-03 | 2015-04-28 | Juniper Networks, Inc. | Media stream transport conversion within an intermediate network device |
| JP5456683B2 (en) * | 2007-10-24 | 2014-04-02 | ラントロニクス・インコーポレイテツド | Various methods and apparatus for a central station for assigning virtual IP addresses |
| US8230050B1 (en) | 2008-12-10 | 2012-07-24 | Amazon Technologies, Inc. | Providing access to configurable private computer networks |
| US8201237B1 (en) | 2008-12-10 | 2012-06-12 | Amazon Technologies, Inc. | Establishing secure remote access to private computer networks |
| US9524167B1 (en) | 2008-12-10 | 2016-12-20 | Amazon Technologies, Inc. | Providing location-specific network access to remote services |
| US9137209B1 (en) | 2008-12-10 | 2015-09-15 | Amazon Technologies, Inc. | Providing local secure network access to remote services |
| CN101778045B (en) | 2010-01-27 | 2012-07-04 | 成都市华为赛门铁克科技有限公司 | Message transmission method, device and network system |
| EP2475145A1 (en) | 2011-01-06 | 2012-07-11 | Research In Motion Limited | System and method for enabling a peer-to-peer (P2P) connection |
| US9882713B1 (en) | 2013-01-30 | 2018-01-30 | vIPtela Inc. | Method and system for key generation, distribution and management |
| US9467478B1 (en) | 2013-12-18 | 2016-10-11 | vIPtela Inc. | Overlay management protocol for secure routing based on an overlay network |
| US10284523B1 (en) * | 2014-03-27 | 2019-05-07 | Amazon Technologies, Inc. | Automatic virtual secure connection using paired network devices |
| RO131252A2 (en) | 2014-11-27 | 2016-06-30 | Ixia, A California Corporation | Methods, systems and computer-readable medium for receiving test configuration information |
| RO131305A2 (en) | 2014-12-15 | 2016-07-29 | Ixia, A California Corporation | Methods, systems and computer-readable media for receiving a clock synchronization message |
| RO131306A2 (en) | 2014-12-16 | 2016-07-29 | Ixia, A California Corporation | Methods, systems and computer-readable media for initiating and executing performance tests of a private network and/or components thereof |
| RO131361A2 (en) | 2015-02-09 | 2016-08-30 | Ixia, A California Corporation | Methods, systems and computer-readable medium for identifying locations associated to endpoints |
| RO131360A2 (en) * | 2015-02-09 | 2016-08-30 | Ixia, A California Corporation | Methods, systems and computer-readable medium that facilitate resolving endpoint hostnames in testing-environment with firewalls, network address translations () or clouds |
| US9980303B2 (en) | 2015-12-18 | 2018-05-22 | Cisco Technology, Inc. | Establishing a private network using multi-uplink capable network devices |
| US10298672B2 (en) | 2015-12-18 | 2019-05-21 | Cisco Technology, Inc. | Global contact-point registry for peer network devices |
| US10374828B2 (en) | 2015-12-18 | 2019-08-06 | Cisco Technology, Inc. | Service-specific, performance-based routing |
| US10681005B2 (en) | 2016-12-08 | 2020-06-09 | Keysight Technologies Singapore (Sales) Pte. Ltd. | Deploying a networking test tool in a cloud computing system |
| US10250564B2 (en) * | 2017-08-21 | 2019-04-02 | Verizon Patent And Licensing Inc. | Dynamically allowing traffic flow through a firewall to allow an application server device to perform mobile-terminated communications |
| US11212260B2 (en) | 2018-03-24 | 2021-12-28 | Keysight Technologies, Inc. | Dynamic firewall configuration and control for accessing services hosted in virtual networks |
Family Cites Families (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5864683A (en) * | 1994-10-12 | 1999-01-26 | Secure Computing Corporartion | System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights |
| US5944823A (en) * | 1996-10-21 | 1999-08-31 | International Business Machines Corporations | Outside access to computer resources through a firewall |
| US5949763A (en) * | 1997-07-17 | 1999-09-07 | Ameritech Corporation | Method and apparatus for providing broadband access conferencing services |
| US6463475B1 (en) * | 1997-09-26 | 2002-10-08 | 3Com Corporation | Method and device for tunnel switching |
| JP3138668B2 (en) * | 1997-11-12 | 2001-02-26 | 日本電気通信システム株式会社 | Virtualized leased line control method and method |
| US6052725A (en) * | 1998-07-02 | 2000-04-18 | Lucent Technologies, Inc. | Non-local dynamic internet protocol addressing system and method |
| US6754831B2 (en) * | 1998-12-01 | 2004-06-22 | Sun Microsystems, Inc. | Authenticated firewall tunneling framework |
| US6434627B1 (en) * | 1999-03-15 | 2002-08-13 | Cisco Technology, Inc. | IP network for accomodating mobile users with incompatible network addressing |
| JP2001160828A (en) * | 1999-12-03 | 2001-06-12 | Matsushita Electric Ind Co Ltd | Vpn communication method in security gateway device |
| US6631416B2 (en) * | 2000-04-12 | 2003-10-07 | Openreach Inc. | Methods and systems for enabling a tunnel between two computers on a network |
| US6996628B2 (en) * | 2000-04-12 | 2006-02-07 | Corente, Inc. | Methods and systems for managing virtual addresses for virtual networks |
| US7181542B2 (en) * | 2000-04-12 | 2007-02-20 | Corente, Inc. | Method and system for managing and configuring virtual private networks |
| JP3597448B2 (en) * | 2000-05-12 | 2004-12-08 | 住友重機械工業株式会社 | Information access method and network system |
| JP2001326693A (en) * | 2000-05-17 | 2001-11-22 | Nec Corp | Communication system and method for controlling communication, and control program recording medium |
| JP2001339428A (en) * | 2000-05-25 | 2001-12-07 | Nec Eng Ltd | Voice/data integrated routing device and voice/data integrated routing method to be used therefor |
| US20020124090A1 (en) * | 2000-08-18 | 2002-09-05 | Poier Skye M. | Method and apparatus for data communication between a plurality of parties |
| US8250357B2 (en) * | 2000-09-13 | 2012-08-21 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
| CA2370934C (en) * | 2001-02-23 | 2004-06-22 | Navaho Networks Inc. | Secure electronic commerce |
| US20020129271A1 (en) * | 2001-03-12 | 2002-09-12 | Lucent Technologies Inc. | Method and apparatus for order independent processing of virtual private network protocols |
| US20020184316A1 (en) * | 2001-04-17 | 2002-12-05 | Thomas Huw K. | System and method for MAPI client server communication |
| US20020186698A1 (en) * | 2001-06-12 | 2002-12-12 | Glen Ceniza | System to map remote lan hosts to local IP addresses |
| US7827278B2 (en) * | 2001-07-23 | 2010-11-02 | At&T Intellectual Property Ii, L.P. | System for automated connection to virtual private networks related applications |
| US20030065785A1 (en) * | 2001-09-28 | 2003-04-03 | Nikhil Jain | Method and system for contacting a device on a private network using a specialized domain name server |
| US7127477B2 (en) * | 2001-11-06 | 2006-10-24 | Everyware Solutions Inc. | Method and system for access to automatically synchronized remote files |
| US20030135616A1 (en) * | 2002-01-11 | 2003-07-17 | Carrico Sandra Lynn | IPSec Through L2TP |
| GB2391436B (en) * | 2002-07-30 | 2005-12-21 | Livedevices Ltd | Server initiated internet communication |
| US7685317B2 (en) * | 2002-09-30 | 2010-03-23 | Intel Corporation | Layering mobile and virtual private networks using dynamic IP address management |
-
2002
- 2002-01-18 US US10/052,094 patent/US20030140142A1/en not_active Abandoned
-
2003
- 2003-01-15 EP EP03710675A patent/EP1466262A1/en not_active Withdrawn
- 2003-01-15 WO PCT/US2003/001188 patent/WO2003069493A1/en not_active Application Discontinuation
- 2003-01-15 JP JP2003568549A patent/JP2005518117A/en active Pending
- 2003-01-15 CA CA002471283A patent/CA2471283A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20030140142A1 (en) | 2003-07-24 |
| EP1466262A1 (en) | 2004-10-13 |
| JP2005518117A (en) | 2005-06-16 |
| WO2003069493A1 (en) | 2003-08-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20030140142A1 (en) | Initiating connections through firewalls and network address translators | |
| US11190489B2 (en) | Methods and systems for establishing a connection between a first device and a second device across a software-defined perimeter | |
| JP5456683B2 (en) | Various methods and apparatus for a central station for assigning virtual IP addresses | |
| US8561147B2 (en) | Method and apparatus for controlling of remote access to a local network | |
| US7308710B2 (en) | Secured FTP architecture | |
| US20140075505A1 (en) | System and method for routing selected network traffic to a remote network security device in a network environment | |
| US20050114490A1 (en) | Distributed virtual network access system and method | |
| US20080005290A1 (en) | Terminal reachability | |
| US8555371B1 (en) | Systems and methods for management of nodes across disparate networks | |
| US9203694B2 (en) | Network assisted UPnP remote access | |
| WO2005053273A1 (en) | Secure communications within and between personal area networks by using private and public identifiers | |
| WO2010127610A1 (en) | Method, equipment and system for processing visual private network node information | |
| EP1328105B1 (en) | Method for sending a packet from a first IPsec client to a second IPsec client through a L2TP tunnel | |
| CA3021367A1 (en) | Using wlan connectivity of a wireless device | |
| US11910193B2 (en) | Methods and systems for segmenting computing devices in a network | |
| EP3454520B1 (en) | Virtual private networks without software requirements | |
| JP2004328029A (en) | Network access system | |
| JP2012044668A (en) | Various methods and apparatuses for tunneling of udp broadcasts | |
| US20150381387A1 (en) | System and Method for Facilitating Communication between Multiple Networks | |
| JP2007519356A (en) | Remote control gateway management with security | |
| EP1413095B1 (en) | System and method for providing services in virtual private networks | |
| Cisco | Configuration Forms | |
| Cisco | Configuration Forms | |
| Cisco | Configuration Forms | |
| Cisco | L2TP Security |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |