08-07-2011 10:26 AM
How to secure remote access to home appliances that were designed for LAN only ? Unfortunately, most residential clients have a consumer ISP's proprietary box, often with a dynamic public address only. Anyways, the TCP port of an appliance cannot be left wide open waiting for hackers.
I want to use a 1721 (or any better IOS router) to provide VPN remote access behind their NAT box (and do the ADSL/routing parts when there is no consumer box). Will it need a second ethernet interface to connect to the appliance, or can the VPN access be done on a stick with a small unmanaged switch, just using a loopback interface and a secondary ethernet address on fastethernet0 ? Only authenticated access to a single LAN address is really needed, strong encryption is overkill. Thanks for all config hints.
08-07-2011 10:28 AM
s/secondary ethernet address/secondary ip address/
08-24-2011 01:09 PM
Hi Emmanuel,
Could you attach a topology of what you are trying to achieve? Still not sure i understood your requirement.
Regards,
Prapanch
08-24-2011 03:10 PM
Hi Prapanch,
I was trying to achieve this topology
but it may be too far-fetched, and I found acceptable to disable NAT on the ISP's box (it can be used as a DHCP server offering a single public address, and still retains its VoIP functions through another ATM VC) then do NAT and VPN on the Cisco, at the price of an additional WIC-1ENET. Here is the new topology:
Using a secondary address on the LAN interface, only the traffic from the CAN bus adapter is routed to a static Virtual Tunnel Interface. The last problem was the left router only gets a dynamic address then the static VTI was broken after each address change. I fixed it with EEM on the right router:
event manager applet Refresh_DynDNS
event timer cron name Refresh_DynDNS cron-entry "*/5 * * * *"
action 1 cli command "enable"
action 2 cli command "configure terminal"
action 3 cli command "interface Tunnel 0"
action 4 cli command "tunnel destination peer.dyndns.host.name"
08-24-2011 03:29 PM
Glad to know you managed to get it working. Thanks for haring the information as well. Will certainly help in case someone else is looking for a similar deployment.
Regards,
Prapanch
09-07-2011 07:50 AM
New problem: the tunnel goes down after the destination being refreshed with an outdated adddress without DNS lookup, despite the peer has had enough time to update the dyndns servers. A ping in exec mode is successful, so forcing lookup seems to fix it:
event manager applet Refresh_DynDNS
event timer cron name Refresh_DynDNS cron-entry "*/5 * * * *"
action 1 cli command "enable"
action 2 cli command "configure terminal"
action 3 cli command "interface Tunnel 0"
action 4 cli command "do ping peer.dyndns.host.name"
action 5 cli command "tunnel destination peer.dyndns.host.name"
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide