On Friday 13 January 2012 10:22:04 am you wrote: > On Friday 13 January 2012 10:17:21 am you wrote: > > On Friday 13 January 2012 9:17:20 am Lloyd Standish wrote: > > > On Fri, 13 Jan 2012 01:25:45 -0600, Andrew Beverley > > > > <andy@xxxxxxxxxxx> wrote: > > > > Using marks is one way to do this, and provides plenty of > > > > flexibility. However, if all the traffic is coming from > > > > the same IP address / interface, then you should be able > > > > to use straight iproute2 rules to match those aspects, > > > > without even touching iptables (see ip rule). > > > > > > > >> iptables -t mangle -A PREROUTING -m state --state NEW > > > >> -s 10.x.x.x -j CONNMARK1 > > > > > > That's a good point. In my own firewall, at one point I > > > wanted to avoid load-balancing for certain hosts (i.e., > > > always route through a given interface for a certain source > > > IP), and I was unable to use "ip rule" with no packet > > > marking. However, I think this is because all the hosts > > > were internal LAN hosts using SNAT, and the NAT is done > > > before the packet hits "ip rule." Therefore "ip rule" > > > could not match on the source IP. But in Dimitri's case, > > > since there is no NAT for the DMZ hosts, this should work > > > fine, and is simpler. The only reason to mark packets would > > > be to allow the possibility of later routing some of the > > > LAN hosts through the second interface. > > > > > > >Also, if you do decide to use netfilter marks (which is > > > > certainly no bad thing IMHO), then you probably don't > > > > need to mark connections and then restore them. Instead > > > > just mark a packet straight away: iptables -t mangle -A > > > > PREROUTING -s 10.x.x.x -j MARK --set-mark 1 > > > > > > Another very good point for Dimitri, Andy, which should > > > give better efficiency. Connection marking is only > > > necessary for load-balancing. I guess I am in a > > > "load-balancing" mindset. > > > > > > -- > > > Lloyd > > > -- > > > To unsubscribe from this list: send the line "unsubscribe > > > netfilter" in the body of a message to > > > majordomo@xxxxxxxxxxxxxxx > > > More majordomo info at > > > http://vger.kernel.org/majordomo-info.html > > > > Lloyd, > > > > Not to throw a proverbial wrench in the works, but in my case > > there is NAT for the DMZ hosts. > > > > I have three NICs currently active on the fw (more are > > available): eth0 - WAN, eth1 - LAN, eth2 - DMZ. In addition, > > eth0 has several aliases for the external addresses of the > > DMZ boxes. Then, NAT to internal addresses (10.x.x.x). > > > > Hope I'm not muddying the waters but, rather, providing all > > of the info that you need to so kindly help me. > > > > Dimitri > > Er, sorry, seems like I don't even remember my own network > scheme. internal LAN addresses are 192.168.100.0/22, and > internal DMZ addresses are 192.168.1.0/24. (The 10.x.x.x > addresses are used by our VPN.) > > Dimitri Lloyd, et. al., Before I commit this new set-up, I'd like to post the ste-by-step instructions I wrote up for your kind review: New WAN provider: IP LAN block - 75.x.x.24/29 GW - 75.x.x.30 Static IPs - 75.x.x.25-29 Internal addresses of DMZ hosts: 192.168.1.3 192.168.1.7 1. Create new interface eth3 for new WAN connection DEVICE=eth0 NETMASK=255.255.255.228 IPADDR=75.x.x.25 NETWORK=75.x.x.24 ONBOOT=yes ETHTOOL_OPTS="autoneg on wol g" 2. Create new interface aliases for servers which will use new WAN, e.g. eth3:0, eth3:1 NAME="" BOOTPROTO=none DEVICE=eth0:0 NETMASK=255.255.255.228 ONPARENT=yes NOZEROCONF=yes IPADDR=75.x.x.26 NETWORK=75.x.x.24 ONBOOT=yes NAME="" BOOTPROTO=none DEVICE=eth0:1 NETMASK=255.255.255.228 ONPARENT=yes NOZEROCONF=yes IPADDR=75.x.x.27 NETWORK=75.x.x.24 ONBOOT=yes 3. Create custom routing table for special DMZ traffic: ip route add 75.x.x.24/29 dev $eth3 src $75.x.x.25 table WAN2 ip route add default via $75.x.x.30 table WAN2 4. Add iptables rules for new WAN Create custom chain: iptables -t mangle -N CONNMARK1 iptables -t mangle -A CONNMARK1 -j MARK --set-mark 1 iptables -t mangle -A CONNMARK1 -j CONNMARK --save-mark iptables -t mangle -A CONNMARK1 -j ACCEPT NEW mark all packets: iptables -t mangle -A PREROUTING -m state --state NEW -s 192.168.1.3 -j CONNMARK1 iptables -t mangle -A PREROUTING -m state --state NEW -s 192.168.1.7 -j CONNMARK1 Restore connection mark to packet mark: iptables -t mangle -A PREROUTING -i $75.x.x.26 -m state --state ESTABLISHED,RELATED -j CONNMARK1 --restore-mark iptables -t mangle -A PREROUTING -i $75.x.x.27 -m state --state ESTABLISHED,RELATED -j CONNMARK1 --restore-mark 5. Add policy routing rule: iprule add fwmark 1 table WAN2 6. Bring down current interface aliases for servers using new WAN; bring up new interface aliases ifdown eth0:1 ifdown eth0:3 ifup eth3:0 ifup eth0:1 Under this set-up, don't I need to add POSTROUTING AND FORWARDING rules? Sorry for my stupidity, but I set the original up a long time ago, and certainly don't know all there is to know. Your continued patience and support are greatly appreciated. Dimitri -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
