Thomas Jagoditsch
2016-09-28 00:53:02 UTC
hi,
ive got a strange problem on my hand with DNAT.
i have some servers running at hetzner in germany, they are pretty all set up the same way.
the physical machine runs libvirt/kvm and there are some vms on a routed but otherwise unconnected bridge which in turn are reachable via DNAT as their different services require.
the vms have access to the outside via masq mostly for updating via the os repos, sometimes they can send smtp too or such stuff.
as i said theses are a couple of servers. i use shorewall since ages and there was never any problem.
yesterday i brought a new host online, this time with current debian instead of the former used ubuntu server variants.
i configured shorewall the very same way as on the other machines but DNAT would not work as expected.
i got
--><--
Sep 28 01:57:20 red_dnat:DNAT:IN=eth0 OUT= SRC=90.146.132.44 DST=138.201.221.81 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=22062 DF PROTO=TCP SPT=57490 DPT=8022 WINDOW=29200 RES=0x00 SYN URGP=0
Sep 28 01:57:20 FORWARD:REJECT:IN=eth0 OUT=eth0 SRC=90.146.132.44 DST=10.10.211.32 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=22062 DF PROTO=TCP SPT=57490 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
--><--
(and a connection refused on the client) when trying to ***@8022 a vm defined by the following rule:
--><--
DNAT:info red $SOREX:ssh tcp 8022 # ssh via 8022
--><--
sshing from the host (inside 10.10.221.0/24 ...)works.
attached is a dump and below the very simple configuration ...
as said above i have similar working configs on other hosts.
i rechecked, compared and tried to find if there were some changes in shorewall i didnt know yet, all for hours but to no avail.
as far as i understand the ip tables config this looks valid to me and again i see much similarity to the other working hosts.
i surely must have overlooked something obvious but im getting desperate now :/
maybe someone out there sees my error and can give me a nudge ...
thx in advance
wbr,tja...
config:
--><-- interfaces
red eth0
nsub natbr0
--><-- masq
eth0 10.10.221.0/24
--><-- params
# hetzner monitor
HMON=red:213.133.113.82,213.133.113.83,213.133.113.84,213.133.113.85,213.133.113.86
# hetzner dns
HDNS=red:213.133.100.100,213.133.99.99,213.133.98.98
# ubuntu software updates
UBUNTU_REPOS=red:archive.ubuntu.com,security.ubuntu.com
# debian software updates
DEBIAN_REPOS=red:ftp.de.debian.org,security.debian.org
# home ips
CW_HOME=red:86.56.232.98
# sorex.clockwork.at
SOREX=nsub:10.10.211.32
#LAST LINE -- DO NOT REMOVE
--><-- policy
$FW red ACCEPT
$FW nsub ACCEPT info
all all REJECT info
--><-- rules
# allow ssh via 13422 to phys host
ACCEPT red $FW tcp 13422
# allow monitoring
ACCEPT $HMON $FW tcp 13422
# allow dns
ACCEPT nsub $HDNS tcp domain
ACCEPT nsub $HDNS udp domain
# allow repos
ACCEPT nsub $UBUNTU_REPOS tcp http,https # ubuntu repos
ACCEPT nsub $DEBIAN_REPOS tcp http,https # debian repos
# uidev vm
DNAT:info red $SOREX:ssh tcp 8022 # ssh via 8022
DNAT:info red $SOREX:http-alt tcp http # tomcat via 80
--><-- zones
fw firewall
red ipv4
nsub ipv4
--><--
ive got a strange problem on my hand with DNAT.
i have some servers running at hetzner in germany, they are pretty all set up the same way.
the physical machine runs libvirt/kvm and there are some vms on a routed but otherwise unconnected bridge which in turn are reachable via DNAT as their different services require.
the vms have access to the outside via masq mostly for updating via the os repos, sometimes they can send smtp too or such stuff.
as i said theses are a couple of servers. i use shorewall since ages and there was never any problem.
yesterday i brought a new host online, this time with current debian instead of the former used ubuntu server variants.
i configured shorewall the very same way as on the other machines but DNAT would not work as expected.
i got
--><--
Sep 28 01:57:20 red_dnat:DNAT:IN=eth0 OUT= SRC=90.146.132.44 DST=138.201.221.81 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=22062 DF PROTO=TCP SPT=57490 DPT=8022 WINDOW=29200 RES=0x00 SYN URGP=0
Sep 28 01:57:20 FORWARD:REJECT:IN=eth0 OUT=eth0 SRC=90.146.132.44 DST=10.10.211.32 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=22062 DF PROTO=TCP SPT=57490 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
--><--
(and a connection refused on the client) when trying to ***@8022 a vm defined by the following rule:
--><--
DNAT:info red $SOREX:ssh tcp 8022 # ssh via 8022
--><--
sshing from the host (inside 10.10.221.0/24 ...)works.
attached is a dump and below the very simple configuration ...
as said above i have similar working configs on other hosts.
i rechecked, compared and tried to find if there were some changes in shorewall i didnt know yet, all for hours but to no avail.
as far as i understand the ip tables config this looks valid to me and again i see much similarity to the other working hosts.
i surely must have overlooked something obvious but im getting desperate now :/
maybe someone out there sees my error and can give me a nudge ...
thx in advance
wbr,tja...
config:
--><-- interfaces
red eth0
nsub natbr0
--><-- masq
eth0 10.10.221.0/24
--><-- params
# hetzner monitor
HMON=red:213.133.113.82,213.133.113.83,213.133.113.84,213.133.113.85,213.133.113.86
# hetzner dns
HDNS=red:213.133.100.100,213.133.99.99,213.133.98.98
# ubuntu software updates
UBUNTU_REPOS=red:archive.ubuntu.com,security.ubuntu.com
# debian software updates
DEBIAN_REPOS=red:ftp.de.debian.org,security.debian.org
# home ips
CW_HOME=red:86.56.232.98
# sorex.clockwork.at
SOREX=nsub:10.10.211.32
#LAST LINE -- DO NOT REMOVE
--><-- policy
$FW red ACCEPT
$FW nsub ACCEPT info
all all REJECT info
--><-- rules
# allow ssh via 13422 to phys host
ACCEPT red $FW tcp 13422
# allow monitoring
ACCEPT $HMON $FW tcp 13422
# allow dns
ACCEPT nsub $HDNS tcp domain
ACCEPT nsub $HDNS udp domain
# allow repos
ACCEPT nsub $UBUNTU_REPOS tcp http,https # ubuntu repos
ACCEPT nsub $DEBIAN_REPOS tcp http,https # debian repos
# uidev vm
DNAT:info red $SOREX:ssh tcp 8022 # ssh via 8022
DNAT:info red $SOREX:http-alt tcp http # tomcat via 80
--><-- zones
fw firewall
red ipv4
nsub ipv4
--><--
--
thomas jagoditsch - tjaSoft
softWareEntwicklung - netzWerkManagement
thomas jagoditsch - tjaSoft
softWareEntwicklung - netzWerkManagement