ICMP echo does not work over SNAT

[rzezeski]

The SNat4 action produces a panic when a guest tries to send outbound traffic destined for the Internet Gateway.

> ::status 
debugging crash dump /var/crash/kalm/vmcore.38 (64-bit) from kalm
operating system: 5.11 helios-1.0.21218 (i86pc)
build version: remotes/ci-build/xde-0-gafd7837f27

image uuid: 6f34b505-1a19-6370-b438-e580a85fe48e
panic message: panicked at 'called `Option::unwrap()` on a `None` value', /work/oxidecomputer/opte/opte/src/engine/headers.rs:538:48
dump content: kernel pages only

> $G
C++ symbol demangling enabled
> $C
fffffe007bce6a80 vpanic()
fffffe007bce6b00 rust_begin_unwind+0x8a()
fffffe007bce6b40 core::panicking::panic_fmt::hfcd69d41fa9fd79d+0x2d()
fffffe007bce6b90 core::panicking::panic::h710e604d40f28e68+0x44()
fffffe007bce6c20 opte::engine::rule::HT::run::h1b5372cbdc538114+0x47e()
fffffe007bce6ef0 opte::engine::layer::Layer::process_out_rules::h7320cffce6e1340f+0x9ad()
fffffe007bce7130 opte::engine::layer::Layer::process::h5ba95c0ee56bbf59+0x288()
fffffe007bce7480 opte::engine::port::Port::process::h0ab95889e3395613+0x2131()
fffffe007bce7c40 xde_mc_tx+0x24f()
fffffe007bce7c70 mac_ring_tx+0x43(fffffe596ae57000, 0, fffffe589a8dfd40)
fffffe007bce7cc0 mac_provider_tx+0x85(fffffe596ae57000, 0, fffffe589a8dfd40, fffffe58ee7a72c0)
fffffe007bce7d80 mac_tx+0x295(fffffe58ee7a72c0, fffffe589a8dfd40, 0, 1, 0)
fffffe007bce7e40 viona_tx+0x48c(fffffe59818c6c80, fffffe59818c6dc0)
fffffe007bce7ea0 viona_worker_tx+0x73(fffffe59818c6dc0, fffffe59818c6c80)
fffffe007bce7ef0 viona_worker+0x11b(fffffe59818c6dc0)
fffffe007bce7f00 thread_start+0xb()

> fffffe589a8dfd40::list mblk_t b_cont|::mblk
            ADDR FL TYPE    LEN   BLEN              RPTR             DBLK
fffffe589a8dfd40 0  data    98    138   fffffe58f92726e8 fffffe589a8ddc80

> fffffe58f92726e8::print -t struct ether_header 
struct ether_header {
    struct ether_addr ether_dhost = {
        ether_addr_t ether_addr_octet = [ 0xa8, 0x40, 0x25, 0xff, 0x77, 0x77 ]
    }
    struct ether_addr ether_shost = {
        ether_addr_t ether_addr_octet = [ 0xa8, 0x40, 0x25, 0xfa, 0xb3, 0xfb ]
    }
    ushort_t ether_type = 0x8
}

> (fffffe58f92726e8 + 0t14)::iphdr
IPv4 header
SRC                                DST                               
HLEN TOS  LEN   ID    OFFSET TTL   PROTO CHKSUM EXP-CSUM FLGS  
172.30.0.7                         1.1.1.1                           
20   0    84    33651 0      64    1     3849   3849     <DF>

We have a guest trying to send a ping outbound to 1.1.1.1. The failure is in the UlpHeaderAction (ULP = Upper Layer Protocol), where it tries to unwrap the meta arg. This meta arg is the value of the the MetaGroup.ulp value for the packet. In the past, opte treated ICMP as kind of a pseudo ULP by inspecting the message type body. However, it doesn't do that anymore and so in the case of ICMP we will have a MetaGroup.ulp value of None.

In order to hit this the VM instance must be configured without an ephemeral IP; otherwise regular 1:1 NAT is used and the SNAT action is never invoked.

I was actually about to test this very scenario because after some discussion with @rcgoodfellow we realized that we have to have some plan for SNAT'ing ICMP traffic out to external hosts as it dictates how we solve this issue in Boundary Services. I think the solution is either going to be modifying OPTE to once again treat ICMP messages as a sort of pseudo ULP, or to have the SNAT action be special cased for ICMP traffic.

That said, there is also the more general issue of getting rid of all these unwrap() calls in the action code. That requires a bit more thought and its own separate issue.

Tasks

• Fix this issue.
• Write up separate issue around unwrap() in actions.

[rzezeski]

Fixed in 54f64c4.