I had a hard time finding this information, so I’m aggregating it here. What you need:

• ASUS Router with ASUSWRT-Merlin installed
• SSH client you can access the router from
• A device to test your VPN Server (e.g. mobile phone with a data connection)
• An Upstream VPN service

Step 1: VPN Server

Log in to the router and go the the VPN page, then “VPN Server”. Configure the OpenVPN server, really however you want, just note the IP subnet. I will use 10.8.0.0/24 in this writing as the VPN subnet, just replace it with whatever you use.

Step 2: VPN Client

Go to the VPN Client tab and create a connection to your upstream VPN provider. Use their OpenVPN configuration file, username/password, etc. At the bottom, set the “Force Internet traffic through tunnel” to “Policy Rules”. This enables a table of routing rules. This table is evaluated in order, and items marked for VPN are sent to the VPN Client interface. The default is WAN.

Start with your most specific rules. For example, we need all traffic destined for a VPN client to go over the WAN, otherwise it will be sent through the Upstream VPN, and that means the client won’t see it properly as a response, because it will have a different IP. This rule should go BEFORE any catch-all “Send everything through the VPN” rules. So, you could have a table like the following:

You can make this more complicated with some devices on your network using the Upstream VPN and some not using it. You can even follow this guide to have rules that make use of port numbers, mac addresses, or any other firewall matching parameters.

Now, if you test this right now, it won’t work. Why? Well the router knows how to route packets, but it doesn’t know to apply NAT. You need to modify the nat table POSTROUTING chain for that, and AFAIK, that can only be done from a script, not the UI.

Enable SSH on your router (Administration->System) and custom scripts (“Enable JFFS custom scripts and configs” : Yes).

Login via SSH. Go to /jffs/scripts and create the file firewall-start. Make it executable. If the script doesn’t exist, you can just run the following in your SSH session:

echo "#!/bin/sh" > /jffs/scripts/firewall-start
echo "iptables -D POSTROUTING -t nat -s $(nvram get vpn_server1_sn)/24 -o tun1+ -j MASQUERADE" >> /jffs/scripts/firewall-start
echo "ptables -I POSTROUTING -t nat -s $(nvram get vpn_server1_sn)/24 -o tun1+ -j MASQUERADE" >> /jffs/scripts/firewall-start

chmod +x /jffs/scripts/firewall-start

Now, you can restart your router to make it use the script, or just run the script now: /jffs/scripts/firewall-start. This will be run anytime the firewall is cleared and re-enabled (reboot or settings change). Look in the system log for messages about it after a reboot if you have issues.

These rules simply tell the router to perform NAT on any outgoing packets from the VPN clients which are destined for the VPN server(s). This way, the VPN server only sees your router as a single client, and nothing gets messed up.

I hope this helps someone. Send me any questions you may have!

After several hours of getting oscillatory behavior from the register ring with the resets tied to switches, I decided to try a different approach. I had been avoiding using the processing system in the design because I was working at a bench and I assumed that it would be simpler to only deal with the hardware. As part of a class at my university, I was setting up a set of remote-access systems for FPGA development, and I thought I’d try something interesting.

By using a GPIO in the design, I was able to avoid switch bouncing entirely, which seems to have helped. I built a 4-stage ring with a shared reset and an input to force a DATA0 or DATA1 out of one stage (OR with the corresponding signal between the registers).

The GPIO was connected to these 3 control signals, and the outputs of each stage (8 inputs). Setting the reset should bring all 4 registers to NULL, and forcing a DATA value should cause it to propagate to all but one register. The first register to receive that data signal will transition to requesting NULL, and therefore the register before it (the one who’s outputs are being overridden) will remain at null. Once the force_data# line is cleared, register 2 receives NULL and requests data, and so on as the wavefronts cycle.

For more information on register rings, see this post.

The synchronous portion of the design interfaces to this using a GPIO module on a 100 MHz clock. This is almost certainly slower than the NCL portion of the design will operate, but by carefully measuring the system under reset states, or while a force_data# line is active, certain conditions can be tested. The synchronous part of the design has a  lot of platform-specific blocks, but can be simplified to a processor connected to a General-Purpose Input-Output module. The code I used to test the module from the processor is given below (the struct is just used as a way to name bits in the GPIO’s registers).

struct gpio_pins {
    union {
        struct {
            u8 s00 :1;
            u8 s01 :1;
            u8 s10 :1;
            u8 s11 :1;
            u8 s20 :1;
            u8 s21 :1;
            u8 s30 :1;
            u8 s31 :1;
            u32 :24;
        };
        u32 values;
    };
    u32 :32;
    struct {
        u8 rst :1;
        u8 force_data0 :1;
        u8 force_data1 :1;
        u32 :29;
    };
};

int main() {
    // Make a pointer to the pins, using the bitfield to interpret them.
    volatile struct gpio_pins* pins =
            (volatile struct gpio_pins*) (XPAR_AXI_GPIO_0_BASEADDR);
    struct gpio_pins reading0 = *pins;
    pins->force_data0 = 0;
    pins->force_data1 = 0;
    pins->rst = 1;
    struct gpio_pins reading1 = *pins;
    pins->rst = 0;
    struct gpio_pins reading2 = *pins;
    struct gpio_pins reading3 = *pins;
    int a;
    for (a = 0; a < 100; a++) {
        reading3.values |= pins->values;
    }
    if (reading3.values) {
        while (1)
            ;
    }
    pins->force_data0 = 1;
    struct gpio_pins reading4 = *pins;
    for (a = 0; a < 100; a++) {
        if (pins->values != 0x51) {
            while (1)
                ;
        }
    }
    pins->rst = 1;
    pins->force_data0 = 0;
    pins->force_data1 = 1;
    pins->rst = 0;
    struct gpio_pins reading5 = *pins;
    for (a = 0; a < 100; a++) {
        if (pins->values != 0xA2) {
            while (1)
                ;
        }
    }
    pins->force_data1 = 0;
    for (a = 0; a < 1000000; a++) {
        // DATA0 lines should not get set
        if ((pins->values &0x55)) {
            while (1)
                ;
        }
        // at least one DATA1 line should be set
        if ((pins->values &0xAA) == 0) {
            while (1)
                ;
        }
        // at least one DATA1 line should not be set
        if ((pins->values & 0xAA) == 0xAA) {
            while (1)
                ;
        }
    }
    pins->rst = 1;
    pins->force_data0 = 1;
    pins->rst = 0;
    pins->force_data0 = 0;
    for (a = 0; a < 1000000; a++) {
        // DATA1 lines should not get set
        if ((pins->values & 0xAA)) {
            while (1)
                ;
        }
        // at least one DATA0 line should be set
        if ((pins->values &0x55) == 0) {
            while (1)
                ;
        }
        // at least one DATA0 line should not be set
        if ((pins->values & 0x55) == 0x55) {
            while (1)
                ;
        }
    }
    pins->rst = 1;
    return 0;
}

The application first runs static tests, checking that when in reset, all stages output 0 and that when a data value is forced, then the data propagates, but does not fill the ring entirely. The last two loops are testing for the dynamic behavior of the ring. I couldn’t hope to actually measure movement of the waves, so just check that at any given time it is in a valid state, when DATA0 was forced, then no DATA1 lines were asserted and vice versa, and that there was a DATA wave and a NULL wave at all times (as measured). The loops take a couple seconds to run, so I feel confident that any errors would have been caught. I put breakpoints in the while (1) loops, which were not hit, and the breakpoint at the last pins->rst = 1; line always ran. Also if a wave ever disappeared, it shouldn’t have ever come back, so I’m confident that this worked as I wanted it to.

Manual inspection of the values (at low frequency using the debugger reading the GPIO pins) showed that the DATA0/DATA1 lines were behaving as expected as well.

What’s next? I want to do the same experiment with multiple data wavefronts (at least 5 stages) and then start building some simple state machines. After that, I want to look at methods of introducing timing into the system by using a clock or GPIO enable as a data input, with a TH22 gate used to wait for the input to match the wavefront.

I have been running some tests with registers on an FPGA, specifically attempting to create a register ring and see what happens. Unfortunately, I have been getting an inverter loop where not desired (when the registers are released from reset, data lines start flipping). I did not get this behavior without the ring, so I think it’s more or less a delay problem in my design. Additionally, the simulator will not launch for me, which I am working on resolving. The up-side is that I have created several Vivado blocks, which are at least close to working (they appear to work when not in a ring). I believe that once I get the register ring working, I will be able to start moving on the larger designs (finite state machines, etc).

Last week, I took the NCL 2-rail register and tweaked it to work with the FPGA development environment I have access to at my university. Specifically, I put it into Xilinx Vivado 2018.3 as a RTL module in a block design.

Setup

I used a single 2-rail bit configuration and started with just one register. I tied the inputs to switches and the outputs to LEDs. One thing to note is that the from_next signal used to control the forward propagation of wavefronts was attached to the switch through an RC lowpass filter to de-bounce it.

I had to make some changes to the register component due to Vivado’s restrictions. I wanted to use a block design, so I had to make all the ports std_logic​ or std_logic_vector. I had been using a custom record type (ncl_pair) to group the DATA0 and DATA1 lines. For now, I just split them apart into two std_logic_vector(0 to 0) lines.

Aside on switch bouncing: Normally when a switch is flipped, there is a small amount of ‘bounce’ where the contact opens and closes rapidly for a short time (as the contacts get very close). By running the output of the switch through a lowpass filter, the fast on/off cycles are somewhat flattened, so that the output is only rising, or only falling when the switch is flipped. Otherwise, the register would have tried to pass several wavefronts before I could see it. For anyone duplicating this, I used a time constant of about 50 ms.

Testing

The register behaved as I expected it to from simulation. initially, the data outputs were all off (NULL) with the to_prev signal asserted (requesting data). When I activated one of the switches (the bounce would have technically made it toggle between DATA to NULL for a bit, but when NULL, all inputs would be NULL, so it didn’t break anything). As I was still requesting NULL from the register (the from_next switch was left de-asserted) the output from the register was still NULL and it was requesting DATA. When I toggled the from_next input to the register to a request for DATA, it outputted the value I had inputted (DATA0 or DATA1 depending on the test case) and switched to requesting NULL. I de-asserted the data line input and set the from_next request to NULL causing the outputs to switch to NULL.

Extension

With this success, I wanted to see if a slightly more complex test would work as well. I added 4 more registers (5 total). The design was still using one 2-rail bit, but now had the capacity to ‘store’ some wavefronts internally. Remember that a sequence of NCL registers can pass a NULL/DATA wave all the way through or can have several stored (approximately N/2) while they wait to pass them on. This held up in testing.

All the same inputs/outputs were used, but the from_next switch was going into the last register, the to_prev LED cam out of the first register, and the data inputs/outputs were connected to the first/last register. I used the following test pattern with NULL waves between each:

DATA0, DATA1, DATA0, DATA0, DATA1, DATA1

I ran this several times with different orders of adding and removing data from the pipeline. E.g. the first time, I kept adding DATA/NULL at the input as long as the to_prev line kept toggling and removed DATA by toggling the from_next line when the pipeline was full. In the next run, I first added 2 DATA waves, then extracted 2 DATA waves, and so on.

I was able to get the same behavior I saw in simulation, which was very exciting.

Moving Forward

This test has given me some confidence that I can successfully map the NCL components to an FPGA. I plan to move forward by building a Vivado IP library. As I go, I will be making a VHDL library for 2-rail NCL. During my long break from working on this, I took a course that gave me experience with these tools designing hardware modules and using FPGAs to implement systems. During that class, I learned that implementing components structurally has its place, but is often a very slow way to design. I will be working on making a more expressive VHDL library than what I have been working with in previous posts (entirely structural). I will be discussing this more in future posts.

To summarize, I have two sub-projects to work on that are highly connected:

1. Building an expressive VHDL library for Null Convention Logic
2. Creating a Vivado IP Library for the components from (1).

The git repository is currently in a somewhat inconsistent state as I am re-doing the library and many components need to be re-done.