Https NAT failure


#1

I have done a simple install just to test Vyos out and I have a problem I can’t figure out. Nat works, but not for https,
other ports may not work as well. The remote site shows a connection on port 443, but the web browser
times out and never get data back from the remote web server, icmp, ssh, http all seem to work. I am at a loss
as to what to try next. I tried both 1.1.7 and the new 1.1.8 rc1, both behave the same. It is running in a virtual box
VM on ubuntu 16.04 host. Here is the config. Any suggestions?

interfaces {
    ethernet eth0 {
        address 10.192.1.11/24
        duplex auto
        hw-id 08:00:27:9c:53:bd
        smp_affinity auto
        speed auto
    }
    ethernet eth1 {
        address dhcp
        duplex auto
        hw-id 08:00:27:2a:42:24
        smp_affinity auto
        speed auto
    }
    loopback lo {
    }
}
nat {
    source {
        rule 1 {
            outbound-interface eth1
            source {
                address 10.192.1.0/24
            }
            translation {
                address masquerade
            }
        }
    }
}
service {
    ssh {
        listen-address 10.192.1.11
        port 22
    }
}
system {
    config-management {
        commit-revisions 20
    }
    console {
        device ttyS0 {
            speed 9600
        }
    }
    host-name vyos
    login {
        user vyos {
            authentication {
                encrypted-password ****************
                plaintext-password ****************
            }
            level admin
        }
    }
    ntp {
        server 0.pool.ntp.org {
        }
        server 1.pool.ntp.org {
        }
        server 2.pool.ntp.org {
        }
    }
    package {
        auto-sync 1
        repository community {
            components main
            distribution helium
            password ****************
            url http://packages.vyos.net/vyos
            username ""
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    time-zone UTC
}

#2

You say NAT is working, but how? Your MASQ NAT doesn’t care what the port number is you are connecting to. This sounds like a misconfiguration of your VM to me.


#3

I agree it doesn’t make sense to me, spent better part of a day trying to figure it out. I just can’t think of how
the vm could affect some ports and not others. On my web server I do a redirect of all http to https. When i
do a wget of the site, I get a connected ip:80, then it gets the 301 to https, which never returns. So strange,
maybe a new day will bring new ideas.

Ron


#4

This is a strange one, not sure how hardware could do this. It looks like it is a brand of USB
to ethernet dongle I was using on the WAN side. I tried two of the same brand of GigE I had
just bought and same affect, no https, ping, dns and http get through. I pulled them out and put
in an old Apple 100MB dongle and everything started working…


#5

I have a similar problem.

[code]eirik@VyOS-VM-rt1# show nat
source {
rule 100 {
destination {
address 0.0.0.0/0
}
outbound-interface eth1
source {
address 10.99.6.0/27
}
translation {
address masquerade
}
}
}

[edit]
eirik@VyOS-VM-rt1# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description


eth0 10.99.3.12/25 u/u
eth1 10.99.3.212/27 u/u
eth2 10.99.6.1/27 u/u LAN connected to Hypervisor vmbr6
lo 127.0.0.1/8 u/u
10.99.6.255/32
::1/128

[edit]
eirik@VyOS-VM-rt1# show nat
source {
rule 100 {
destination {
address 0.0.0.0/0
}
outbound-interface eth1
source {
address 10.99.6.0/27
}
translation {
address masquerade
}
}
}

[edit]
eirik@VyOS-VM-rt1# run monitor nat source translations
Type control-C to quit
Pre-NAT Post-NAT Prot Timeout Type
10.99.6.5 10.99.3.212 icmp 30 new
10.99.6.5 10.99.3.212 icmp 30 update
10.99.6.5 10.99.3.212 icmp destroy
10.99.6.5 10.99.6.5 icmp 30 new[/code]

This is what happens when i try to ping an outside address from the host 10.99.6.5:

Sometimes first it creates a correct entry in the NAT-table, but after a few seconds it’s destroyed and it creates an entry without translation.