DNA Welho has added IPv6 support to all their cable hookups on June 9th,1 which was a national IPv6 deployment flag day in Finland. I only heard about it from Facebook comments today. Until now I’ve had IPv6 disabled on the private VRF because my fast cable hookup only provided IPv4. Using IPv6 from the DSL hookup would have just slowed things down.
After some poking around I was able to get my VRF-separated home network connected using a delegated prefix. (more…)
I would like to forward SSH from my cable modem interface to an internal box in a different VRF, but this for some reason is only possible using static IP addresses. The global IP address in the NAT statement must be a static one to be able to also include a VRF reference.
This is what I would like to add:
ip nat source static tcp 10.0.0.11 22 interface Vlan6 22 vrf private extendable
However, neither “vrf” nor “extendable” is allowed after “interface” has been entered.
Yet, if Vlan6 has the IP address 192.0.2.123 from DHCP, I can add the following static NAT entry and it works as one would expect:
ip nat source static tcp 10.0.0.11 22 192.0.2.123 22 vrf private extendable
I don’t see why it wouldn’t be possible to add the VRF to an entry that uses an interface reference for the global IP address. (more…)
I wanted to use the OS X VPN client to connect to my home network while on the road. I guess using an OS X server would be the easiest way to get a Mac-compatible VPN server up and running. Using a Cisco running IOS required quite a few lines of configuration.
The OS X VPN client provides terrible feedback. It will happily tell you that there was “no response from the VPN server” when in reality the server responds with a rejection of all the ISAKMP or IPsec transforms proposed by the client. Fortunately both the Cisco debugging messages and verbose output from tcpdump were quite helpful.
In about 3 hours I got it all working, including routing with other VRFs and DMVPN sites. (more…)
Direct connections from PuTTY to Cisco routers kept dying on this error, so I finally ran a search. The workaround is to disable re-key on the SSH session. In the PuTTY settings dialogue, goto
Connection > SSH > Kex
Change the following values to zero:
Max minutes before rekey: 0
Max data before rekey: 0