Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ixel]

Hi all,
This is probably a long shot, but I have a spare dedicated server with an public IPv4 block assigned (/26) via something called a 'virtual rack' on its second LAN interface.

In my mind I thought perhaps I could make temporary re-use of this, until my minimum term has concluded, by somehow pushing some or most of this block to my home connection via something like L2TP. So, I setup an L2TP server and have so far successfully managed to get it so that the Firebrick or any other device connecting to the L2TP server will get a true public IP from this IPv4 block (not NAT'd at all). However, either I'm missing something or what I hope to do isn't physically possible, as I can't use more than one public IP address or with a subnet like /29 or perhaps even /26. The Firebrick doesn't appear to be showing the subnet up in the ARP info either. I've set it up almost identically to how I have the IPv4 /29 via L2TP from AAISP, although I suspect they must do something more than I'm doing in order to make it routable.

I tried to do this on Ubuntu Server with accel-ppp but I guess I needed to setup one or more routes, as I could connect but couldn't ping the IP address of an L2TP connection remotely despite it being assigned a public IPv4 address from the /29 block and equally the connected device was unable to ping an IPv4 address like 8.8.8.8. I'm currently using SoftEther VPN server on Windows for now.

IPv4 /26:
- Gateway: x.x.x.126
- Network: x.x.x.64
- Broadcast: x.x.x.127
- Firebrick IP from L2TP: Currently x.x.x.65

The Firebrick IP address (x.x.x.65) pings fine from a remote location when L2TP has connected.

Any suggestions or questions? Assuming what I want to do is even possible. I'd rather not manually connect to L2TP on each device, if that device was to have a static IPv4. NAT is also out of the question, as I'd prefer the device to truly have a public IPv4 address and not a LAN IP address which the public IPv4 address forwards to.

Optionally I can also remove the allocation from the virtual rack. This means each IPv4 address somehow then has a subnet mask of 255.255.255.255 instead of 255.255.255.192 and the gateway IPv4 address changes to x.x.x.254 (according to the server provider). The network and broadcast address also become assignable/usable IPv4 addresses by doing that, I believe.

[tickmike]

I built my own 'Backup-server' some years ago and that is used by any of the family for there devices backup from anywhere.
It uses ssh to a fixed IP address, keep it simple and it works ok with no issues.

[Ixel]

I built my own 'Backup-server' some years ago and that is used by any of the family for there devices backup from anywhere.
It uses ssh to a fixed IP address, keep it simple and it works ok with no issues.

Nice, but I'm not sure if that really addresses my problem. Unless what you mean is that just having an L2TP connection on each device with a single static IP address is perhaps the only approach I can take?

I did some further reading and I'm wondering if splitting/dividing the subnet is what I need to do, then setup a route. I'm not 100% sure though. What I want to do doesn't seem that easy to accomplish .

For example, the current subnet becomes two subnets:
- x.x.x.64/27 (likely becomes what the Firebrick would hopefully be able to use and perhaps points to a gateway IP in the other subnet)
- x.x.x.96/27 (stays on the remote end where the L2TP server is hosted)

Finally then a route between them. Still trying to figure out of that would really help me though.

[burakkucat]

Hmm . . . I've tried to understand what you would lie to achieve and think it makes sense but "tingles in the whiskers" seem to hint otherwise. Especially as using a Firebrick is something of an unknown to me.

Perhaps CarlT might be best placed to offer a general opinion? 

[Ixel]

Hmm . . . I've tried to understand what you would lie to achieve and think it makes sense but "tingles in the whiskers" seem to hint otherwise. Especially as using a Firebrick is something of an unknown to me.

Perhaps CarlT might be best placed to offer a general opinion? 

Yeah, it's possibly quite complicated to achieve. In my mind I'm thinking it must surely be possible somehow. I feel like I'm close to the answer given that I'm able to get a single static IP working from the original subnet, any single static IP within the usable addresses in that subnet, but when it comes to routing a subnet or even a splitted subnet, I can't seem to get my head around it. For the sake of comparison, I've tried looking at what AAISP's L2TP does with the /29 I have from them... sadly it hasn't really gotten me closer to a solution though.

Hopefully CarlT will drop by and offer some insight!

In the meantime I think I will give Ubuntu or CentOS another shot with accel-ppp. I could at least login and get the IP assigned but I'm guessing I was missing the necessary route(s) to allow internet traffic through. Time to experiment some more for now.

[niemand]

Hello!

Using something like PPP you would have a /30 or /31 out of your /26, you have your tunnel interface on your remote side and give your local device the other IP in the network.

Static route at the remote side pointing a /27 to the single IP from the /30. Give an interface on the LAN side of your kit an IP in the /27 and that's your LAN default gateway for that network.

Bit of policy based routing based on either source or IP or arriving interface to steer traffic properly.

Treat it like an ISP. That's the simplest way from the configuration point of view.

Can also tunnel Ethernet across but depending on your kit and what's available that ups the difficulty slightly.

[Ixel]

Hello!

Using something like PPP you would have a /30 or /31 out of your /26, you have your tunnel interface on your remote side and give your local device the other IP in the network.

Static route at the remote side pointing a /27 to the single IP from the /30. Give an interface on the LAN side of your kit an IP in the /27 and that's your LAN default gateway for that network.

Bit of policy based routing based on either source or IP or arriving interface to steer traffic properly.

Treat it like an ISP. That's the simplest way from the configuration point of view.

Can also tunnel Ethernet across but depending on your kit and what's available that ups the difficulty slightly.

Thanks, that helps clear things in my head quite a bit! At least I now know this is possible, just need to get it configured correctly for this to work. I will continue playing around with it over the weekend, fingers crossed I will get there.

It's quite a learning curve for me, but it also gives me some deeper insight into how an ISP works I guess as well as perhaps being something useful to know in the future.

As for tunneling Ethernet across, I don't think I can do that through a Firebrick sadly. I have an Edgerouter ER-Pro8 which might be able to do that, would need to check though. For now I will try the first approach.

EDIT: What you said regarding setting up a static route to the single IP, which is now /31, works brilliantly. The remote end can ping an IP address on the /27 at the Firebrick's LAN side and the Firebrick's LAN IP address, acting as the gateway, on the /27 can ping to the remote side and the gateway IP on the remote side. Now I assume I just need to figure out policy based routing in order internet traffic to work both in and out. Right now I can only ping as far as the gateway IP on the remote side (x.x.x.126). I feel I'm almost there.

EDIT 2: It turns out there's something else wrong with my setup on Debian (the remote side o/s). I thought I'd try pinging 8.8.8.8 on the second interface that's got an IP address of x.x.x.125/26 going to gateway x.x.x.126, however it's not pinging. I'm looking into that now, I suspect if I can fix that then the L2TP connection may even just start working and have internet access.

EDIT 3: Sadly I'm still stuck with getting internet access to and from the client assigned IPv4 addresses. I just can't seem to figure it out in my head how I'd instruct Linux to handle it.

I've also posted it as a question on stackexchange. I've put tons of detail into the question to hopefully make it clear how my current setup is, so there's minimal uncertainty.

It's at https://unix.stackexchange.com/questions/651988/how-do-i-do-the-required-routes-for-getting-internet-traffic-to-from-my-client

If anyone here knows what I should do then please shout. Any help is welcome!

EDIT 4: I've switched to VyOS, an operating system dedicated to networking and what EdgeRouter's are typically based on. I'm hopeful it might aid me in what I need to get done, I'll continue playing around with it today.

[Ixel]

I'm not sure if I should post a new reply, so that it's obvious this thread has been updated, or whether I should still just edit the previous reply.

Well anyway... for the curious... after further experimentation, I think I've started to grasp the importance and usefulness of policy based routing, although a bit late. The good news is that I've now got what I want fully working but in a sort of roundabout way.

I'm using CentOS with SoftEther VPN Server (L2TP). With this I currently have 32 connections/logins setup, on the Firebrick they each have their own routing table. Each of them also have a unique public IPv4 address. SoftEther has been the only way I've managed to successfully get an internet connection without NAT, I believe because it makes a virtual network interface (hidden to the O/S) which bridges the L2TP connections and the ethernet interface (e.g. eth1/eno2) on an ethernet level.

With this, I've instructed the Firebrick's firewall through dozens of rules to jump between the various routing tables for each L2TP connection and the routing table that the port for my LAN has, and vice versa. The LAN interface still uses my public IPv4 /26 but realistically it's not directly connected to the IP addresses allocated to my L2TP server connections. The first IP of that public IPv4 /26 block isn't really public facing, it's only used as a gateway IP for my LAN port and that IP isn't reachable from the internet. This works, although as I say it's a roundabout way of doing it. I still have spare IP addresses too, so can add more logins later on.

Finally, the DHCP server is configured so that it will issue a static IP address based on the local hostname. The Firebrick has such a setting for each L2TP connection, so it's easy to allocate static IP addresses.

It didn't take long to do the configuration manually as I used a program called NimbleText. This saves me a lot of time when it comes to do doing repetitive lines of text with certain minor differences.

[burakkucat]

Thank you for the update. I'm pleased to know you now have things configured to operate correctly.

[Ixel]

Not to bring up an old thread intentionally, but I figure this might be useful information for some people who may stumble across this thread.

I've recently changed my setup from using SoftEther VPN Server (L2TP), for which each IP address I wanted on my home network each had its own L2TP login/session and some trickery with the firewall. I came across a thread on another forum, typically for discussion of servers and such, which gave a handy guide on how to use a GRE tunnel to route a block of public IPv4 addresses to another location. The tutorial had a use case of tunneling DDoS protected public IPv4 addresses (as a subnet) from a server to another location which has a server running virtual machines. I slightly modified this so that my router could provide the IPv4 addresses from the block to one or more devices on my LAN instead.

Unfortunately, from what I can see, the FireBrick 2900 doesn't have the capability of setting up a GRE tunnel. So, I ended up using my EdgeRouter Pro 8. For some reason I was unable to configure the GRE tunnel and policy routing via the config tree, I could do so but it wouldn't work. However, manually running the commands in the tutorial via SSH, as well as running an additional command so I also had a route for my LAN IPv4 addresses, worked fine. I believe I've managed to persist these commands on power cycles of the router by putting a script in the post-config.d folder. Setting eth3 to be the first IPv4 address of the block was fine via the config tree.

For those curious or interested, the tutorial I came across is at https://www.lowendtalk.com/discussion/156850/howto-tunnel-ddos-protected-ovh-ip-to-vms-in-other-datacenter/p1

Assume 83.x.x.169 is the IPv4 address of my EdgeRouter and 51.x.x.62 is the IPv4 address of the server at the datacenter which has the block of public IPv4 addresses available. The mentioned block we'll also assume is 198.x.x.0/24.

I ran the following on the server at the datacenter:

Code: [Select]

/usr/sbin/ip tunnel add gre1 mode gre remote 83.x.x.169 local 51.x.x.62 ttl 255
/usr/sbin/ip link set gre1 up
/usr/sbin/ip route add 198.x.x.0/24 dev gre1
/usr/sbin/iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Then I ran the following on my EdgeRouter here, at home:

Code: [Select]

/sbin/ip tunnel add gre1 mode gre remote 51.x.x.62 local 83.x.x.169 ttl 255
/sbin/ip link set gre1 up
/sbin/ip rule add from 198.x.x.0/24 table 666
/sbin/ip route add default dev gre1 table 666
/sbin/ip route add 198.x.x.0/24 dev eth3 table 666
/sbin/ip route add 192.168.1.0/24 dev eth1 table 666
This must also be run on both sides:

Code: [Select]

sudo echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sudo sysctl -p
Finally, 198.x.x.1/24 was added as an IPv4 address to the eth3 interface on the EdgeRouter via the UI - which is the gateway.

A device on my home network can then do something like the following:

Code: [Select]

IP Address: 198.x.x.2
Subnet Mask: 255.255.255.0
Gateway IP Address: 198.x.x.1
The subnet range must be at least /30 or the tutorial won't work.

Obviously this is trickier to do if you don't have a static IPv4 address with your ISP or your router isn't capable of running a GRE tunnel. It can't be done behind NAT either.

Suffice to say I'm pleased with the outcome, as the L2TP setup I had before wasn't perfect and sometimes if for some reason my PPPoE connection dropped (that's extremely rare) then a few of these L2TP connections were sometimes oddly unable to get any internet access until I either reconnected the troublesome L2TP connections once or maybe twice, or at an extreme I would have to reboot the FireBrick. The benefit of this is I'm no longer relying on needing an ISP to sell a small block of IPv4 addresses and if I change to another ISP then these IPv4 addresses come with me, as I hope to do at some point very soon because of a local rollout.

EDIT: I was having issues with downloading some things every so often via any of the public IPv4 addresses, turned out I forgot about the MTU. If you're on a PPPoE connection make sure the MTU is set correctly (e.g. should be 1468 or lower on the GRE tunnel on both ends). For me I had initially got it set to a slightly higher MTU on the server's side while the MTU was correct on my Edgerouter's side. Was puzzling me for a little while.

EDIT 2: Forgot to include mention of net.ipv4.ip_forward needs to be '1' on both sides or it won't work at all.

EDIT 3: Added MSS clamping instruction, otherwise certain websites appear to struggle to load I've noticed (particular with SSL/TLS). Doing MSS clamping on the datacenter's server resolves that problem.

[burakkucat]

Thank you for an (another) update.    I shall try to see if I can understand exactly what you have achieved. 

[Ixel]

Thank you for an (another) update.    I shall try to see if I can understand exactly what you have achieved. 

Basically I've routed a block of (DDoS protected) public IPv4 addresses, that are assigned to a server in a datacenter, to my home network via a GRE tunnel. Network devices on my LAN can directly use them if they are assigned an IPv4 address from that block. No NAT involved. Similar to how you would use an IPv4 address from a small block of static IPv4 addresses (e.g. /29) that a customer might request/order from an ISP who offers that option/addon.

The nice thing about a GRE tunnel is that there's no authentication, it's just simply point to point and it's stateless. It just sends encapsulated packets whether or not one of the endpoints are online or offline, with minimal overhead. It can, if needed, also transport some protocols that a VPN connection can't necessarily do - it's somewhat like having a very long ethernet cable between two locations I guess.

I didn't really know about GRE until I saw that tutorial, then I took a little time to read about it and thought wow this could be perfect for what I'm aiming to do. Turns out it was the answer!

[burakkucat]

The nice thing about a GRE tunnel is that there's no authentication, it's just simply point to point and it's stateless. It just sends encapsulated packets whether or not one of the endpoints are online or offline, with minimal overhead. It can, if needed, also transport some protocols that a VPN connection can't necessarily do - it's somewhat like having a very long ethernet cable between two locations I guess.

Ah, with that analogy, I think I've "got it"!

I didn't really know about GRE . . .

That is a new TLA for me. I need to do some research.

[Alex Atkin UK]

I've never used GRE but it seems to be basically the same principle as GIF which I use for IPv6 over Plusnet via HE.net.  Although I have no hosts using IPv6 as I found it problematic, I keep it on the router so DNS can still use it.  Its extremely reliable, never failed to come up unlike OpenVPN which regularly gets stuck in an offline state.

I did try the Xbox as IPv6 only, it didn't work, it seems to require IPv4 to function despite Microsoft claiming back before Xbox One launched that it would work entirely over IPv6, but I digress.

Biggest problem is just how expensive IPv4 is now due to them being a scarce resource.

[Ixel]

I've never used GRE but it seems to be basically the same principle as GIF which I use for IPv6 over Plusnet via HE.net.  Although I have no hosts using IPv6 as I found it problematic, I keep it on the router so DNS can still use it.  Its extremely reliable, never failed to come up unlike OpenVPN which regularly gets stuck in an offline state.

I did try the Xbox as IPv6 only, it didn't work, it seems to require IPv4 to function despite Microsoft claiming back before Xbox One launched that it would work entirely over IPv6, but I digress.

Biggest problem is just how expensive IPv4 is now due to them being a scarce resource.

I looked up GIF and yeah I agree, the principle seems to be identical. Funny you say that OpenVPN regularly gets stuck in an offline state, as that sounds a little similar to the problem I occasionally had with some of the L2TP connections. Yeah, GRE so far for me has just worked, relatively simple to setup.

Unfortunately there's still many things out there which need IPv4. Yes, blocks of IPv4 addresses can be pretty pricey now due to their shortage. At the moment I'm just paying the provider for the rental cost of the server. Renting a block of IPv4 addresses from them doesn't currently incur a monthly charge unless they are 'parked' (only a setup charge based how many you need). They did charge a monthly price in the past, like most services usually do.