1

I use Ubuntu server as router, NATing router and webserver. The server is connected to ISP with a public /29 subnet. Also I host some important websites on it. I asked the ISP to provide ipv6 address block. They say that the router where my link terminates at ISP does not have ipv6 support. So they said that if I'm ready connect to their edge router via a private 172.16.x.x/30 subnet, they can provide me ipv6 block. However, they'll give me a public ipv4 /29 routed to me via 172.16.x.x/30 which I can use to host my websites. But the problem that I have is that I do not want to buy another router so that I can put 172.16.x.x/30 on the ISP facing interface and the public /29 on another interface facing my server and NATing router.

What I want to know is if I can use 172.16.x.x/30 to connect to ISP and also use the public /29 on the same Ubuntu server to host websites and to do NATing. My router has more than 5 NICs and I can use vlans also.

ISP's edge router supports ipv6 but the reason why they cannot directly give me a public subnet is this. At present my link terminates at a switch which is connected to the edge via 172.16.x.x.

nixnotwin
  • 1,543
  • 5
  • 35
  • 55

2 Answers2

2

Using RFC1918 addresses for router-to-router connections is frowned upon if it's on the public Internet, especially when used on an interface between the ISP and the customer (as opposed to between two routers inside the ISP network). This is because they reduce the usefulness of traceroute due to some sites blocking all packets to or from these addresses and because it is not possible to attach meaningful names to these addresses via DNS PTR records, because they cause routers to originate ICMP messages that cannot be traced back to their source, and possibly other reasons besides. However, it sounds like your ISP is set on using a RFC1918 /30 to number the interface between them and you. Despite the recommendation not to do it, it will actually work fine, and you can accommodate this situation with only one difficulty (see below).

The ISP's complaint about ARP trouble with a subnet larger than /30 sounds bogus. It is true that a router's performance can be affected by useless ARP requests for non-existent addresses on an interface with a large sparse subnet, but the subnet has to be both large and sparse (contain very many unused addresses) for this to happen. This is because only ARP requests for addresses that aren't used on the subnet must be endlessly timed out and repeated, which is how the router would get bogged down. If they upgraded your interface to a (public) /29, it would be neither large nor sparse (I am assuming that you would actually use all or almost all of the addresses on the /29). People are legitimately worried about ARP problems with /64 IPv6 subnets (which are obviously large and will always be sparse since the number of hosts on the subnet will never approach the maximum) but it sounds ridiculous to worry about it for a /29.

There is good news with this configuration: because the ISP isn't configuring your public /29 on any interface, there is no need to reserve the first and last IP address of the block as broadcast addresses, nor is there a need for the ISP to consume one of the addresses on their own router. So you get to use all 8 addresses for yourself instead of only 5.

Here's what you do:

  1. Configure the interface facing the ISP with the 172.16.x.x/30 address provided by the ISP.

  2. Add the /29 block to the lo interface: /etc/network/interfaces:

    iface lo inet loopback
            up ip addr add a.b.c.d/29 dev lo
    
  3. Set your default gateway to the ISP's side of that link 172.16.x.otherside.

    Now comes the difficulty I mentioned earlier: by default, when your server initiates outbound connections (DNS requests, email going out, software update checks, outbound connections to databases, or whatever else your server does that is initiated by itself rather than by a client contacting the server), the server will use 172.16.x.x as the source address of the packets because that is the address attached to the interface through which the packets are going to egress. When the server attempts to contact destinations on the Internet at large using this source address, it will obviously not work. You need to give an option to the route command to install a default route with a customized source address.

    Omit the normal gateway 172.16.x.otherside entry and configure this instead in /etc/network/interfaces:

    iface ethSOMETHING inet static
            [other configuration directives]
            up ip route add default via 172.16.x.otherside src a.b.c.d
    

    For a.b.c.d, choose one of the addresses from your /29 which you consider to be your server's "main" address.

Celada
  • 6,200
  • 1
  • 21
  • 17
  • What you have suggested would be the most feasible solution. I need bit more help with the solution you have provided. Can I use any one ip from the public `/29` block on the `lo` interface? Should that ip be similar to the one configured as `a.b.c.d` on `up ip route add default via 172.16.x.otherside src a.b.c.d`? If I want to use few more ips from the `/29`, on which interface I should add them? Would I be able to masquarade (NAT) ethSOMETHING interface directly? And finally whould my `localhost` domain name resolve to `127.0.0.1` normally? – nixnotwin Jun 30 '12 at 17:21
  • 1
    You can place as many of the 8 IPs as you wish onto the server's `lo` interface. In my answer, I have suggested that you place all 8 of them there (the whole /29). Once they are on the `lo` interface, they are all usable as source IP addresses, addresses that the server may hosts sites on, addresses for SNAT, etc... You could also place fewer IP addresses on the `lo` interface by (for example) breaking up the /29 into 2 /30s, adding one of them to `lo`, and routing the other one to another server, where it could be added to the `lo` interface of that other server. Or have 4 /31s, 8 /32s, etc.. – Celada Jun 30 '12 at 18:11
  • But the `src` ip (default gateway) on the ISP facing interface would be one "main" ip from the `/29`, which if I had put in a router (in between ISP and my server) I would have used it as a gateway for my server. – nixnotwin Jul 01 '12 at 01:09
  • 1
    I am struggling a little bit to understand what you mean by your last comment... Yes, it's true that if you were to put in an extra router between your server and the ISP you would probably assign one IP from the /29 onto that router's interface that is facing your server and it would become your server's default gateway. But you aren't intending to put in such a router, so you don't need to allocate an address in this way. All 8 from the /29 can go onto your server's loopback interface. Then the default gateway is `172.16.x.otherside` and you need `src` to force the choice of source address. – Celada Jul 01 '12 at 03:40
  • You have understood my last comment. What that `src` be? Imagine I got a subnet 220.239.49.176/29. So I would put `220.239.49.176` as `src` on ISP facing interface (the interface that has 172.16.x.x ip). And I should assign ips from 220.239.49.176 - 183 to `lo` interface. – nixnotwin Jul 01 '12 at 12:38
  • Correct. One small correction in terminology: `220.239.49.176` isn't the `src` parameter on the ISP facing interface (there's no such thing as `src` parameter on an interface), it's the `src` parameter on the *default route*. – Celada Jul 01 '12 at 13:25
  • For NATing I'll be using this: `iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 220.239.49.177` In this iptables rule what should be the `-o` interface be? Is it `eth0` (ISP facing interface) or `lo` where the public ips from `/29` are? – nixnotwin Jul 03 '12 at 00:56
  • The `-o` should be `eth0`, the ISP-facing interface. This matches packets intending to head out toward the Internet and SNATs them, which is what you want. By the way, using `lo` in `-i` or `-o` of iptables rules never matches anything. Linux uses separate chain names like `INPUT` and `OUTPUT` instead to signify locally originated or locally terminated packets. – Celada Jul 03 '12 at 10:56
  • I did the setup today and its working well. Even NATing also works.How can I setup iptables rules to block ports on the public network? Also I want port 80 to be accessible on the public network. – nixnotwin Jul 03 '12 at 12:24
  • iptables rules should work as usual, but are out of scope for this question (and long threads of comments like this aren't what serverfault is designed for). You'll want to be blocking and/or permitting inbound or outbound on `eth0`, your interface toward the ISP. – Celada Jul 03 '12 at 14:29
  • I tried `iptables -A INPUT -i eth0 -j DROP` And I lost access to public network. At present my server is online with all the ports open. So I need any simple rule, at least to block all the ports temporarily. – nixnotwin Jul 03 '12 at 14:37
  • 3
    Dude, the `lo` interface should **never** have any addresses other than 127.0.0.0/8. – mgorven Jul 03 '12 at 18:05
  • @mgorven why not? Where would YOU put IP addresses not associated with any physical interface? – Celada Jul 03 '12 at 19:23
  • @Celada In this case the addresses can probably all go on `eth0`, but otherwise a bridge or tun interface. – mgorven Jul 03 '12 at 19:30
  • @mgorven creating a bridge with no members or a tun to nowhere doesn't seem right. In networking, it's standard to place IP addresses that belong to a system without being associated to any particular physical interface on the loopback interface. Cisco IOS even expects you to do this: it gives preference to the (non-127.0.0.1) IP address on a loopback interface for use as a router ID for OSPF and BGP (among others). Under Linux it's a great way to add a whole block of addresses to the system without adding then one by one because Linux uses the prefix length to consider the whole block local. – Celada Jul 03 '12 at 21:39
0

I asked the ISP to provide ipv6 address block. They say that the router where my link terminates at ISP does not have ipv6 support.

We're all looking forward to the day when that goes away, but unfortunately that's still most of the world I know.

So they said that if I'm ready connect to their edge router via a private 172.16.x.x/30 subnet, they can provide me ipv6 block. However, they'll give me a public ipv4 /29 routed to me via 172.16.x.x/30 which I can use to host my websites. But the problem that I have is that I do not want to buy another router so that I can put 172.16.x.x/30 on the ISP facing interface and the public /29 on another interface facing my server and NATing router.

Ouch, more or less. Here's what I read as happening: their router is going to give you a 6 to 4 tunnel over a private IP space with a next-hop of some other router in their network. It will also use an interior routing protocol that proclaims that your private-space system is the next-hop address for your public address space.

What I want to know is if I can use 172.16.x.x/30 to connect to ISP and also use the public /29 on the same Ubuntu server to host websites and to do NATing. My router has more than 5 NICs and I can use vlans also.

ISP's edge router supports ipv6 but the reason why they cannot directly give me a public subnet is this. At present my link terminates at a switch which is connected to the edge via 172.16.x.x.

It sounds to me like what you should be doing is placing the exterior addresses of everything you want to server to serve via one external interface that is hooked up to the router. Assign everything to eth0 and various subinterfaces (eth0:0, eth0:1, etc.) and set your default gateway to be the interface of their router.

Jeff Ferland
  • 20,547
  • 2
  • 62
  • 85
  • If I implement your suggestion I would add `172.16.x.x/30` to `eth0` and all the public ips from `/29` to subinterfaces (eth0:0, eth0:1, etc.). If I ping from the server (router) to a public ip, then gateway and source address used would be from `172.16.x.x/30` and I wouldn't reach public network. Or I could try `ip route add default via 172.16.x.otherside src my.pub.ip` (from Celeda's anwser) and assign the pub ips to `eth0:0, eth0:1` instead of `lo`. – nixnotwin Jul 04 '12 at 01:22