Reconstructing / resending packets on a VOIP call doesn't help, as it is too late. VOIP needs decent prioritised QOS to work. If you get bits of audio out of order or dropped, retransmits can't help you as its too late by that point (the listener didn't get the audio in time - they hear a bit of silence in the audio).
The only real way of making it work is ensuring VOIP traffic is prirotised so that it doesn't get dropped in the first place. Hence different cost/QOS rules to other generic data that is extremely tolerant of out of order packets and delays.
Unlike streaming audio / video from youtube or whatever, you can't simply buffer 30 sec of audio to work around this, as two-way conversations are real time...
SSH open to the world is pretty stupid yes, however you can restrict it to known-good hosts (as you should with any internet facing service where this is possible).
If you implement SSH properly (i.e., use public keys, and firewall incoming port 22 to only known good hosts) having your machine compromised via this vector is FAR less likely than the other exposed remote services such as DNS, SMTP, etc.
Anyone who thinks that NAT is a replacement for a firewall is a fool.
There is zero need for NAT when you can replace all the brain damage and application incompatibility with 2 lines of firewall config for the same effect.
A small SOHO network should be less reliable than the ISP it plugs into. if it is not, your ISP and/or link technology is shit and needs to be replaced.
In any case, the re-addressing issue is moot if you know how to use DNS and autoconfiguration properly anyway.
Also: why are you relying on IP addresses? Your external IP changes with IPV4 anyway. With IPV6 your subnet will change, your internal hosts are allocated new IPS, re-register with DNS and shit just works.
The rest of the world doesn't need to maintain IPV4 brain damage because you can't maintain your network properly.
Remove the BS in dealing with NAT and we can move onto solving other more important problems. keeping broken shit to keep people employed reinventing the wheel is not productive - and essentially productivity is what provides human advancement. if we're wasting time dealing with brain damage just to maintain teh status quo, then why bother? I know this is government strategy for maintaining jobs, but it shouldn't be.
The my internet comment was facetious, but in my experience most of the XP holdouts are clueless and by and large the major component of the botnets launching DOSes that I have to deal with day in day out.
My main point is that technology moves on. The C64 died, the Amiga died, Windows 98 died, etc. Bringing the future of the internet to a halt because of some tight-arse fucktards who don't want to get off some antiquated insecure OS is going to be a net LOSE for everybody.
Either get with the program, or don't maintain connectivity to the internet. I don't care. There are literally billions of other people on the planet impacted by the shortage of IPV4, and hundreds of thousands of network admins who have to deal with NAT brain damage every day. It needs to stop.
You need to read up on how IPV6 works, at least at a rudimentary level. Your router will be allocated a subnet. A route is created to you for that subnet. Any device behind your router will get an IP on that subnet, no new routes are needed every time you plug in a device.
You can replace your NAT with something like this for a firewall (in cisco ACL):
ip access-list extended ingress
remark IP access list for WAN connection inbound
remark permit inbound connections that were previously established from internal hosts only
permit tcp any [subnet allocated] established
permit tcp any host [internal host] [allowed port] ... repeat above line for any services you DO wish to expose, or don't even bother with the above line if you wish to expose nothing
Apply that to your external WAN interface inbound. Done. This could be automated on any router as a secure default - no NAT brain damage required.
FTP is hard to NAT because it uses 2 connections (one control, 1 data) and NAT routers are not very good at keeping track of state for BOTH connections as a single transfer, when dealing with both incoming and outgoing FTP. Also, the IP address is embedded in the command channel, and NAT packet mangling doesn't look into the command channel and modify this to suit what NAT is doing to the packets, unless you have fairly clever packet inspection going on.
That's kinda moot anyway, because FTP is broken and needs to die also (use SFTP insteaed). I'm not SIP expert, but I suspect similar issues are going on there as well. IPSEC security is weakened somewhat when traversing a NAT as well.
We can keep making firewalls and routing tables more complex (and thus, prone to programming bugs and thus security holes), or we can bite the bullet and go to a clean, flat IP address space and get away with much less complicated routing, firewalling, etc.
Adding complexity as you increase network size simply WILL NOT SCALE - never mind the fact that NAT also has practical limits which we will exceed in due course as well.
Do you need to print to your printer from anywhere on the internet?
Maintain IPV4 (dual stack with IPV6) on your LAN for broken shit that doesn't support IPV6, and move on. Enjoy the freedom of real routing for the devices that DO have a benefit from being able to route properly that this brings.
Mod parent up. If you've had to deal with any sort of reasonably larged sized network and NAT, everything he mentions above is a huge pain in the ass. Relying on NAT as a "firewall" is brain damaged anyway, and those who tihnk NAT needs not processing ability compared to a proper firewall are deluded. Every single packet needs to be looked up against the NAT state table, so even though you don't have any real firewall rules, processing is still going on.
The "protection" that NAT provides can be replaced with a real firewall simply blocking incoming connections and maintaining state on outgoing connections - without breaking NAT incompatible protocols to boot.
I can't wait for the IPV6 migration to hit en-masse. Those with a clue will be in huge demand.
What about all the commodore c64 owners out there? XP is a turd that needs to be dropped. It is out of date, insecure and unsupported. If you don't like Windows 7, then change to something else - there are plenty of viable alternatives.
We have 3.7bn IPV4 addresses. That won't even cover 1 device per person, before even taking into account losses due to subnetting. The population is growing exponentially, and we should probably plan on the number of IP enabled devices growing even faster than that (higher number of devices per person).
NAT, large scale or otherwise is only a band-aid delaying the inevitable.
Its a horrible hack that breaks many protocols and causes all sorts of problems when you want to (say) join two previously private networks together only to find that they're using the same internal network range.
NAT got us through the late 90s while IPV6 was being finalized. It is truly time to let IPV4 go and get on with the changeover. Other countries (china) are already implementing large-scale IPV6 networks due to an inability to acquire IPV4 - so it can certainly be done.
All I'm saying is that you may end up getting faster app change time, but reducing performance in the app(s) while actually using them.
At the end of the day, ram is cheap - if you're waiting for the app to be paged in then it had to be paged out because you don't have enough RAM. Yes, disabling disk cache may free more RAM, but you'll probably just kill all i/o throughput in the process.
Despite popular opinion - Microsoft developers are not completely retarded when it comes to performance tuning. Win7 / 2008 / other products of this generation have been made to work well at the majority of tasks, with hardware spec expected during the product's life-cycle.
Of course there are cases where this may not be exactly right (hence you can turn shit like superfetch off, and tweak kernel parameters if you look it up), especially during the early days of the OS's life. People seem to forget that when XP itself was released, it was a complete dog compared to Windows 2000 or 98 unless you gave it an appropriate amount of RAM. The min spec was 32 meg; I challenge anyone to try running it with that and not rage-quitting the OS...
AS you see more modern hardware becoming more common, the performance advantages of 7 over XP are only going to grow.
Slashdot Mirror
Then use a mirror that isn't shit.
Reconstructing / resending packets on a VOIP call doesn't help, as it is too late. VOIP needs decent prioritised QOS to work. If you get bits of audio out of order or dropped, retransmits can't help you as its too late by that point (the listener didn't get the audio in time - they hear a bit of silence in the audio).
The only real way of making it work is ensuring VOIP traffic is prirotised so that it doesn't get dropped in the first place. Hence different cost/QOS rules to other generic data that is extremely tolerant of out of order packets and delays.
Unlike streaming audio / video from youtube or whatever, you can't simply buffer 30 sec of audio to work around this, as two-way conversations are real time...
*cough*. KDE was good in the 2.x and 3.x days...
SSH open to the world is pretty stupid yes, however you can restrict it to known-good hosts (as you should with any internet facing service where this is possible).
If you implement SSH properly (i.e., use public keys, and firewall incoming port 22 to only known good hosts) having your machine compromised via this vector is FAR less likely than the other exposed remote services such as DNS, SMTP, etc.
Yes.
Anyone who thinks that NAT is a replacement for a firewall is a fool.
There is zero need for NAT when you can replace all the brain damage and application incompatibility with 2 lines of firewall config for the same effect.
I can take small segments of curves out of context and make them look flat too.
Currently our population growth has slowed down, but you think that trend is going to continue when we start colonizing other planets?
Stop looking at tiny time-scales, and look at the big picture...
In any case, the re-addressing issue is moot if you know how to use DNS and autoconfiguration properly anyway.
Good luck when your company merges with another that is using the same private network.
Read how BGP works.
Also: why are you relying on IP addresses? Your external IP changes with IPV4 anyway. With IPV6 your subnet will change, your internal hosts are allocated new IPS, re-register with DNS and shit just works.
The rest of the world doesn't need to maintain IPV4 brain damage because you can't maintain your network properly.
If you need carrier redundancy, BGP is your solution, not IPV4 + NAT.
Look at population growth. Exponents are still exponents, even if they're not on a scale of powers of 10.
Remove the BS in dealing with NAT and we can move onto solving other more important problems. keeping broken shit to keep people employed reinventing the wheel is not productive - and essentially productivity is what provides human advancement. if we're wasting time dealing with brain damage just to maintain teh status quo, then why bother? I know this is government strategy for maintaining jobs, but it shouldn't be.
The my internet comment was facetious, but in my experience most of the XP holdouts are clueless and by and large the major component of the botnets launching DOSes that I have to deal with day in day out.
My main point is that technology moves on. The C64 died, the Amiga died, Windows 98 died, etc. Bringing the future of the internet to a halt because of some tight-arse fucktards who don't want to get off some antiquated insecure OS is going to be a net LOSE for everybody.
Either get with the program, or don't maintain connectivity to the internet. I don't care. There are literally billions of other people on the planet impacted by the shortage of IPV4, and hundreds of thousands of network admins who have to deal with NAT brain damage every day. It needs to stop.
You need to read up on how IPV6 works, at least at a rudimentary level. Your router will be allocated a subnet. A route is created to you for that subnet. Any device behind your router will get an IP on that subnet, no new routes are needed every time you plug in a device.
You can replace your NAT with something like this for a firewall (in cisco ACL):
ip access-list extended ingress
... repeat above line for any services you DO wish to expose, or don't even bother with the above line if you wish to expose nothing
remark IP access list for WAN connection inbound
remark permit inbound connections that were previously established from internal hosts only
permit tcp any [subnet allocated] established
permit tcp any host [internal host] [allowed port]
Apply that to your external WAN interface inbound. Done. This could be automated on any router as a secure default - no NAT brain damage required.
FTP is hard to NAT because it uses 2 connections (one control, 1 data) and NAT routers are not very good at keeping track of state for BOTH connections as a single transfer, when dealing with both incoming and outgoing FTP. Also, the IP address is embedded in the command channel, and NAT packet mangling doesn't look into the command channel and modify this to suit what NAT is doing to the packets, unless you have fairly clever packet inspection going on.
That's kinda moot anyway, because FTP is broken and needs to die also (use SFTP insteaed). I'm not SIP expert, but I suspect similar issues are going on there as well. IPSEC security is weakened somewhat when traversing a NAT as well.
We can keep making firewalls and routing tables more complex (and thus, prone to programming bugs and thus security holes), or we can bite the bullet and go to a clean, flat IP address space and get away with much less complicated routing, firewalling, etc.
Adding complexity as you increase network size simply WILL NOT SCALE - never mind the fact that NAT also has practical limits which we will exceed in due course as well.
Maintain IPV4 (dual stack with IPV6) on your LAN for broken shit that doesn't support IPV6, and move on. Enjoy the freedom of real routing for the devices that DO have a benefit from being able to route properly that this brings.
Mod parent up. If you've had to deal with any sort of reasonably larged sized network and NAT, everything he mentions above is a huge pain in the ass. Relying on NAT as a "firewall" is brain damaged anyway, and those who tihnk NAT needs not processing ability compared to a proper firewall are deluded. Every single packet needs to be looked up against the NAT state table, so even though you don't have any real firewall rules, processing is still going on.
The "protection" that NAT provides can be replaced with a real firewall simply blocking incoming connections and maintaining state on outgoing connections - without breaking NAT incompatible protocols to boot.
I can't wait for the IPV6 migration to hit en-masse. Those with a clue will be in huge demand.
This is what DNS is for.
Or - get off my internet.
We have 3.7bn IPV4 addresses. That won't even cover 1 device per person, before even taking into account losses due to subnetting. The population is growing exponentially, and we should probably plan on the number of IP enabled devices growing even faster than that (higher number of devices per person).
NAT, large scale or otherwise is only a band-aid delaying the inevitable.
Its a horrible hack that breaks many protocols and causes all sorts of problems when you want to (say) join two previously private networks together only to find that they're using the same internal network range.
NAT got us through the late 90s while IPV6 was being finalized. It is truly time to let IPV4 go and get on with the changeover. Other countries (china) are already implementing large-scale IPV6 networks due to an inability to acquire IPV4 - so it can certainly be done.
All I'm saying is that you may end up getting faster app change time, but reducing performance in the app(s) while actually using them.
At the end of the day, ram is cheap - if you're waiting for the app to be paged in then it had to be paged out because you don't have enough RAM. Yes, disabling disk cache may free more RAM, but you'll probably just kill all i/o throughput in the process.
Despite popular opinion - Microsoft developers are not completely retarded when it comes to performance tuning. Win7 / 2008 / other products of this generation have been made to work well at the majority of tasks, with hardware spec expected during the product's life-cycle.
Of course there are cases where this may not be exactly right (hence you can turn shit like superfetch off, and tweak kernel parameters if you look it up), especially during the early days of the OS's life. People seem to forget that when XP itself was released, it was a complete dog compared to Windows 2000 or 98 unless you gave it an appropriate amount of RAM. The min spec was 32 meg; I challenge anyone to try running it with that and not rage-quitting the OS...
AS you see more modern hardware becoming more common, the performance advantages of 7 over XP are only going to grow.
I'm not sure where that memory shows in terms of usage.
You can turn that off, but again, its memory being put to use rather than sitting there idle.
I haven't tested with it off vs on, but some have and noticed it does speed up application launch after it "learns" what to keep pre-fetched. YMMV...
Thing is if you have an enterprise agreement or technet sub - you get win7 upgrade for free...