Tuesday, August 2, 2011

OSX and VPN Expiration Issues

After updating to Lion the VPN config began expiring every hour as it was doing in Snow Leopard until I fixed with tips from this site:
From the site, it appears to not apply for Lion, but it does in fact work fine.
By following those directions, your vpn connection to Cisco will stay up for hours :)
Technical Tips

Tuesday, February 15, 2011

World IPv6 Day: at AppalachianWireless.com

IPv6 is here to stay!

There is plenty of room for growth, new options, and more devices.
And there is a public IP address for everyone.

Due to the ever growing data usage and customers, Appalachian Wireless will be participating in the World IPv6 Day.

This means that when you access www.appalachianwireless.com you will have direct IPv6 or IPv4 access.
If you are on a network that already supports IPv6, than you will connected direct to appalachianwireless.com via IPv6.
If you are still running IPv4, you will be able to continue to access the site via IPv4.

Today, you can already test your IPv6 access by connecting to ipv6.appalachianwireless.com and verifying your network access.

If you are on an ISP who is behind and not able to give you an IPv6 address, there are a number of options available including http://tunnelbroker.net/.

You Always Get More with Appalachian Wireless:

Wednesday, January 19, 2011

ping6 and slow responses

While trouble shooting an IPv6 issue, I discovered that "ping6 <my_ipv6_host>" was getting very delayed responses.

After running tcpdumps and every other debug method I could think of, I finally determined with the help of a friend, that reverse DNS was not setup for <my_ipv6_host>. After fixing this, the ping6 time was like it should have been.

So, do you have a slow ssh or slow ping6 times?
Check for valid reverse DNS.

Wednesday, January 5, 2011

IPv6 and neighbour soliciting

In dealing with a FireWall Router mf-firewall [1] setup and testing, I ran into an issue where my interfaces on my linux box looked like this:

Bonded Interface -> 2 network real network cards
  creating device bond0:

The vlan interfaces where all based on the bond0 device, so all traffic went into the vlan device, than off course exited the bond0 device.

Doing a tcpdump on vlan5 for a workstation located there, I could not see the neighbour requests. Doing the same dump on bond0 I could see it.
Of course the device on vlan5 was not getting the neighbour solicit command.

Finally after some research I was able to fix this with this command:
" echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp "

Hopefully this can save someone else some grief.
Perhaps someone else has a better fix.

[1] http://code.google.com/p/mf-firewall/