Hello,
I have a NetBSD 3.0.1 firewall, and I'm trying to bring
a second DSL service online, just for ssh/scp connections
to one host in a DMZ.
The network looks like this (apologies for ASCII art ....)
_______________
DSL1 service (default) -------| sip0 |
| |
DSL2 service (bridge) -------| pppoe0/sip2 |
| |
| sip1 |----- target host in DMZ
| | (routable IP)
| |
| fxp0 |----- LAN (192.168.1.0/24)
----------------
I hope my diagram makes sense.
The DSL2 service's IP address is 218.214.135.250, and the next
hop is 202.154.95.67
The DSL1 service is fully routable, works fine, never been a problem
etc.
What I'm trying to set up is a policy route such that traffic
inbound on the DSL2 link, which has it's own single real IP
address, gets mapped to an alias on the target host (eg 192.168.2.2)
and that ssh connections in to it get routed back out through pppoe0,
rather than the default route on sip0 (DSL1)
So, I have this in ipf.conf :
# setup rules while I set up the DSL2 link on sip2
pass in log quick on sip2 from any to any
pass out log quick on sip2 from any to any
pass in log quick on pppoe0 from any to any
pass out log quick on pppoe0 from any to any
# Policy routing for DSL2 link
# special rules to allow ssh in to goshu via the DSL2 interface on
# pppoe0 - keep state
# doesn't seem to work with this stuff ...
pass out log quick on sip0 to pppoe0:202.154.95.67 from 218.214.135.250
to any
pass out log quick on sip0 to pppoe0:202.154.95.67 from 192.168.2.2 to any
pass out log quick on sip1 proto tcp from any to 192.168.2.2 keep state
pass in log quick on sip1 from 192.168.2.2 to any
pass out log quick on sip1 from 192.168.2.1 to any
ifconfig for pppoe0 shows :
plug: {56} ifconfig pppoe0
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
inet 218.214.135.250 -> 202.154.95.67 netmask 0xff000000
inet6 fe80::209:5bff:fe1b:7497%pppoe0 -> prefixlen 64 scopeid 0x6
and for sip2 (the ethernet interface hosting pppoe0)
plug: {58} ifconfig sip2
sip2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:09:5b:1b:78:bd
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::209:5bff:fe1b:78bd%sip2 prefixlen 64 scopeid 0x4
ifconfig.pppoe0 :
plug: {59} more ifconfig.pppoe0
create
! /sbin/ifconfig sip2 up
! /sbin/pppoectl -e sip2 $int
! /sbin/pppoectl $int myauthproto=pap 'myauthname=XXXXXXX' 'myauth
secret=XXXXXXXX' hisauthproto=none
0.0.0.0 0.0.0.1 up
The link is up, and I can telnet(!) to the pppoe0 interface from the
outside with no problems, and also chargen, so I think MTU is ok? I'm
not blocking icmp 3/4 packets.
aditionally, my ipnat.conf has this :
rdr pppoe0 0.0.0.0/0 port 23 -> 192.168.2.2 port 23
rdr pppoe0 0.0.0.0/0 port 22 -> 192.168.2.2 port 22
So I *think* all tcp traffic on port 22 (& 23 while I test!)
should be mapped to the internal host's alias and back again
on the way out? I'm not 100% sure where IPF does its NAT (I grew
up on firewall-one and always get these the wrong way around
accordingly!)
I have two problems outstanding. Firstly, when I just try and
ssh to the firewall itself, (with the ipnat RDR rule disabled,
of course!) I get an initial connection, and then a hang, which
-feels- like an MTU problem, as I can connect to it with telnet and
log in ok, and telnet'ing to the chargen port shows lots of big
packets flowing ok. I tried shrinking the MTU of my originating
host down to 1000, and it made no difference. If I run sshd -D on
the firewall it sees the first section of the connection, and then
seems to hand, but if I ^C it, the client sees a HUP and shuts down,
so there's something getting through. ipmon shows no blocked
packets, but does IPF silently block icmp if it thinks it's illegal?
Secondly, can anyone see what I've done wrong with my RDR rule?
Attempts (even telnet!) to the target server are not replies, I
think I broke the RDR rule?
IPF is :
plug: {62} ipf -V
ipf: IP Filter: v4.1.8 (396)
Kernel: IP Filter: v4.1.8
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 0
Feature mask: 0x10a
Thanks for any help, I've been beating my head against this for
days now and am well and trully stuck, and my client is not amused!
Carl
--
=======================
Vivitec Pty. Ltd.
Suite 6, 51-55 City Rd.
Southbank, 3006.
Ph. +61 3 8626 5626
Fax +61 3 9682 1000
=======================
