Well I was actually just issuing some dry humor there, but now I'm going to have to try using .0 and see if it works.
Of course, if you want to confuse the heck out of people, use .0 or .255 in a network that's bigger than /24. For example, 172.16.1.0/23 or 172.16.0.255/23.
That'll quickly call out the people who don't know how to think in CIDR and only understand octets. (ProTip: these are the same dweebs who still refer to a /24 network as "a Class C," particularly when they are requesting /24 of public IPv4 space for their rack of three servers. Not gonna happen in 2016.)
I've seen it used successfully in a class before. It gave me a double-take, as it isn't very conventional.
Someone just asked me what route metrics to use to get hosts on a 192.168.60.0/24 network talking over a VPN to hosts on a remote 192.168.60.0/24 network.
The labor day weekend drinking is going to have to start early, I think.
Use the auto-recombobulator with transparent bidirectional DS-NAT. And then punch the dumb fuck in the face.
The punching or the DS-NAT?
DS-NAT. Punching is straightforward, unless you plan to use a right hook.
We replaced a Cisco 2811 router with a Fortigate 240D. It handles routing between a number of IP networks at a site, with one handoff to a WAN. In the not too distant future it'll replace the site's Internet firewall as well, but that hasn't been done yet.
Complaint received the next day: the network staff can't reach about a dozen Cisco ethernet switches at their admin addresses. The switches are carrying layer 2 traffic just fine, so there isn't any outage, but the switches can't be reached for maintenance. Interestingly, they are still reachable when we go to another device on the same subnet and ping or ssh over to them.
"It's all the switches in building XX," they said. Nope, I found switches in building YY that are unreachable, and switches in building XX that are reachable.
"The Fortigate can't handle multinetted interfaces properly," they said.
(Yes, that interface was multinetted; the reason is legit but irrelevant.)
Well, I was willing to believe that, but couldn't prove it, since *most* of the things on there were working.
IP address conflict? Nope. Checked that. MAC address conflict? Nope.
While trying to figure out WTF, I changed the IP addresses of one of the problem devices to an address on the router interface's primary address, thinking it was a problem with that. Didn't fix it. But then the NOC said the device started alerting in monitoring. What? How was it working in monitoring when it wasn't working anywhere else?
I got a packet trace going on the Fortigate. (Note: Fortinet's on-router sniffer BLOWS AWAY anything Cisco has.) Got a continuous ping going from my laptop to the device in question. And I see the device issuing ARP requests for hosts that are *not* on its local management network. Again ... WTF?!? Then ... since I'm so old-skool, I noticed that these requests were only being issued for hosts on the SAME CLASSFUL NETWORK (10.x.x.x).
So I stared at the configuration some more. And then it hit me:
ip route 0.0.0.0 0.0.0.0 10.xxx.xxx.xxx
The specified gateway was correct ... but this statement wasn't doing a damn thing. It wasn't working. And it had *never* worked. I changed it to:
ip default-gateway 10.xxx.xxx.xxx
And ... BOOM. Reachable from everywhere. So why was the device reachable before we changed the upstream router?
The device is a Catalyst 3750. I went down the list, and found that every unreachable device was a 3750, and they all had "ip route 0.0.0.0 0.0.0.0 10.x.x.x" statements. That's how you set the default gateway when the device is running in Layer 3 routing mode. These aren't. When IP is only used for management, you have to use the "ip default-gateway 10.x.x.x" command. So again, why was it working before?
There is ancient code in the IOS IP stack, which makes it try things like ARP and CDP to find a way off the local network when the default gateway is not specified. The old Cisco router was answering those requests and supplying us with the default gateway. Like I said, the "ip route" command was there, but it wasn't being honored. It was working for the wrong reason.
Damn, but that's subtle. Good work.
Hi, i think i am in the right place here, after ready that last bit of net-voodoo (fu to you, voodoo to me ;) ). So, i have a question:
What are the pros and cons of having, a fixed IP address, so i can access my files and run a couple of server from home?
I have a friend in the biz 30 years said it's a big no-no, not secure having one static IP. But have read there is not much difference security wise between this and a dynamic address.
Any thoughts on securing a static IP?
Not having a static IP at home is just security by obscurity.
Especially since you say that you want to run some services. If you do so, you need a method to access the dynamic IP, which is done most of the time by using a dynamic DNS service, such as dyndns.org (a big no no!) or afraid.org (they are cool) or others. That means, your home is reachable via that dynamic address and the bots and assholes are ready to fire.
Then there are the servers you reach from your dynamic IP address. For example, people could read the "Online users" list here regularly and will always be able to attack user Mo under his address. Connection to an IRC network? Yet another source.
I run a server at home for over 10 years now and the logs always show various degrees of connection attempts from strangers. Therefore, the usual measures apply:
Keep your system up to date, especially after you hear about sever faults in some software, the kernel or maybe even your modem/router hardware.
Use fail2ban or denyhosts for the services that are open on the net, apply some simple iptables rules that ban people who connect to fast. (You will shoot yourself in the foot at least once with these countermeasures!)
If you must connect home, think about using VPN. Have everything reachable only by connecting through VPN. That might make it harder for friends to reach your FTP server, but it decreases the attackable surface.
That is the bare minimum, everything else can be done according to your degree of paranoia.
There are also tips like "use port knocking" or "change the default port". As if a computer would not be able to scan every open port on your system either rapidly or slowly. Look at what nmap can do in various degrees of aggressiveness and then think again if changing your ssh port to 2222 is a smart move.
Subject: Re: Net Fu
I ran Uncensored on a home server with a static IP address for 11 years.
I don't think we ever had an attack that would have been preventable by having a dynamic IP address. That's what proper firewalls and other good security practices are for.
I don't have anything to add to that, beyond, 'Ditto'.
I don't think there's enough of a difference between dynamic and static IP addresses, security-wise, to warrant the inconvenience.
From there, embrace your paranoia as far as you wish to go.
Thanks guys, sage advice i think: that is why i asked here.
I told one of my oldest friends who is a network engineer (he's between contracts if anyone needs a good man to maintain their network in the UK/London area - or anywhere else?? ;) ), a while back, and he said that a fixed IP might be a bad idea. I however have as my first point of call, on setting up a home network, a book by Roderick W Smith "Linux Networking for your Office, as my introduction to networking (along with his book on broadband internet for home users),
and the advice he gives is, dynamic or fixed IP both have similar security risks so use whatever method. So
I have used my fixed IP to run a gopher server, as a test - so port 70 is not blocked by my ISP ( i used PyGopherd, written by John Goerzen, who frequents this board ).
Hopefully citadel's default port (504 ?) is not blocked.
I'll stick with the static IP for convenience sake, and read up on securing my system then.
I have to admit that none of my clients has a static IP, all of them use some dynamic dns service. Some might have an isp contract with an opt-in option, but for some unrational gut-feeling I have never applied for a static IP in their name. For security feelings. Since you can't call that a reason. :)
I have kind of an annoying problem. It's annoying because it looks like it should be sooper easy, but instead, it has consumed a full day for me.
I've posed it here:
This said, I'm trying to use iptables to port-forward from a selection of adaptes on a linux server to localhost. The trick, though, is that the number for the port doesn't necessarily match between localhost and the adapter.
I plan to have apache2 running such that it is only accessible directly via localhost, then to use iptables to open the pages to particular adapters on specific ports (as a configuration option). I want to take this approach because I might use one port for one adapter, but a totally different port on a different adapter.
Any ideas on how to do this? Is iptables perhaps not the right tool, and I need to do something funky with netcat instead?
we in the past have used something like stunnel to route between ports. YMMV.
I might need to do something like that.