Tom & Simon
> you have an invalid IP configuration since the subnet between modem and
> firewall is the same as your internal network. Thus it's not possible to
> correctly route traffic to allow internal devices to access the modem.
Thanks for pointing that out.
A quick change/test to
[net]
|
------------------------
EXT: DHCP Client
Uverse/ATT modem (bridge mode)
INT: DHCP Server & WebServer @ http://192.168.1.254
------------------------
|
|
------------------------
EXT: DHCP Client -> IP == 1.2.3.4
Linux Router/Firewall (shorewall)
INT: 10.0.1.100
------------------------
|
|-------------------------------|
------------------- -------------------
EXT: 10.0.1.10 EXT: 10.0.1.20
Linux Laptop Linux MailServer (temp)
------------------- -------------------
and
SHOREWALL/shorewall.conf
NULL_ROUTE_RFC1918=No
ROUTE_FILTER=No
SHOREWALL/masq
(empty)
SHOREWALL/routes
(empty)
appears to solve the ACCESS problem. I am able to browse to
http://192.168.1.254
from the 10.0.1.0/24 LAN.
>
> What you need to do is renumber one or other of the networks so that the
> subnets do not overlap.
> Once you have done that, you'll find that the modem is directly reachable -
> though you may need to relax your RFC1918 filtering*.
>
> If you don't change your masq config, then the modem will see traffic coming
> from your external address. You can alter that by specifying (from memory)
> "net:!192.168.2.0/24" in your masq config file (assuming you'd changed the
> modem to be in the 192.168.2.0/24 subnet).
>
> * If you are still using (from memory) norfc1918 which IIRC is deprecated,
> then you'll need to remove it and apply rules. You need to add permit rules
> for the outside private network. So you'll need rules like :
> permit lan net:192.168.2.0/24
> deny lan net:192.168.0.0/16
> deny lan net:172.16.0.0/12
> deny lan net:10.0.0.0/8
>
> You are filtering RFC1918 traffic on egress aren't you ?
Now, for access control/filtering of the rfc1918 nets, after reading
http://shorewall.net/manpages/shorewall.conf.html
http://shorewall.net/MultiISP.html#null_routing
, what I've had is embarrassingly sloppy.
Starting to clean up, with
SHOREWALL/shorewall.conf
NULL_ROUTE_RFC1918=No
ROUTE_FILTER=No
SHOREWALL/interfaces
net EXT_IF
optional,physical=eth0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
vpn1 VPN_IF
optional,physical=tun1,logmartians=0,routefilter=0,routeback=1
- INT_IF
physical=eth1,dhcp,tcpflags,logmartians=1,routefilter=0
SHOREWALL/providers
ISP01 1 0x100 main EXT_IF detect
track,balance INT_IF
VPN01 2 0x200 main VPN_IF 10.254.254.1
track,fallback INT_IF
SHOREWALL/routes
ISP01 10.0.0.0/8 blackhole
ISP01 172.16.0.0/12 blackhole
# ISP01 192.168.0.0/16 blackhole
# ISP01 192.168.1.254/24 - eth0
I've still got access to the 'net AND the modem's webserver.
But if I add the 192. rfc1918 block to the restrictions, with and exlcusion for
the modem's webserver,
SHOREWALL/routes
...
- # ISP01 192.168.0.0/16 blackhole
- # ISP01 192.168.1.254/32 - eth0
+ ISP01 192.168.0.0/16 blackhole
+ ISP01 192.168.1.254/24 - eth0
On compile I get an ERROR,
...
Adding Providers...
RTNETLINK answers: Invalid argument
ERROR: Command "/sbin/ip -4 route add 192.168.1.254/24 dev eth0
table ISP01" Failed
Restoring Shorewall Lite...
...
I'm not clear if uncommenting those two lines is incorrect, or correct with a
problem elsewhere. (Looking at those permit/deny 'rules' ... are those
generated when /routes are sepcified?
Re-reading, I'm not sure I've got the right settings in shorewall.conf, and for
routefilter= in /interfaces. Particularly whether when using /routes with "...
blackhole ..." if I need to ALSO specify other than NULL_ROUTE_RFC1918=No in
shorewall.conf.
In any case, what needs to be fixed in my config above to retain access and
properly filter rfc1918 egress?
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
