[ale] Iptables wierdness

[Alex Carver]

Oh, well that's just Comcastic. :)

Everything seemed fine with the tables, if state NEW didn't do anything
then I agree it's likely external.

On 2015-02-17 15:15, Jim Kinney wrote:
> On Tue, Feb 17, 2015 at 5:58 PM, Alex Carver <agcarver+ale at acarver.net>
> wrote:
> 
>> Are these the rules entirely or did you edit?
>>
> 
> I pulled out the rules for the working vIP and changed the external IPs.
> 
>>
>> If edited, there might be a rule matching and preventing these from
>> triggering.  I would also try adding NEW to the ESTABLISHED,RELATED
>> state clause and see if that opens up anything.
>>
> 
> No change :-(
> 
>>
>> On one of my firewalls, I have a blanket --state RELATED,ESTABLISHED (no
>> NEW) for the entire ruleset and then I add a separate --state
>> NEW,RELATED,ESTABLISHED onto the more specific rules:
>>
>> -A INPUT -m state --state INVALID -j DROP
>> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>> -A INPUT -s <source IP> --dport <port> -m state --state
>> NEW,RELATED,ESTABLISHED
>>
>> (replace INPUT as needed of course)
>>
>> How did you insert your SNAT/DNAT entries (They look correct, just
>> double checking).
>>
> 
> My usual way - manual edit of the /etc/sysconfig/iptables file :-)
> 
> I'm beginning to suspect that Comcast may have the route broken.
> 
> If I turn off the pre/post routing rules for the bad IP and let the gateway
> just have 2 IPs on the same NIC, I _STILL_ can't ping the IP from outside.
> Earlier testing had tcpdump with the nat route in place showing traffic
> going out _from_ the bad IP but nothing returning.
> 
> <sigh> I think it's time to call Comcast tech support.
> 
>>
>> On 2015-02-17 14:34, Jim Kinney wrote:
>>> I reworked the network setup to use the new IPADDR0, IPADDR1, IPADDR2
>>> format for vip's. I even let NetworkManager run things. No changes. The
>>> internal 192.168.1.12 address is not reachable from the outside over it's
>>> external IP nor can it reach the outside. Everything else is
>>> SNAT'ed/DNAT'ed just fine.
>>>
>>> iptables -L -n -t nat
>>> Chain PREROUTING (policy ACCEPT)
>>> target     prot opt source               destination
>>> DNAT       all  --  0.0.0.0/0            13.160.95.6
>> to:192.168.1.12
>>>
>>>
>>> Chain INPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain POSTROUTING (policy ACCEPT)
>>> target     prot opt source               destination
>>> SNAT       all  --  192.168.1.12         0.0.0.0/0
>> to:13.160.95.6
>>>
>>> iptables -L -n
>>> Chain INPUT (policy DROP)
>>> target     prot opt source               destination
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     all  --  0.0.0.0/0            127.0.0.0/24
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state
>>> RELATED,ESTABLISHED
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp
>> dpt:500
>>> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
>>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp
>> dpt:4500
>>> ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            policy
>> match
>>> dir in pol ipsec udp dpt:1701
>>> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
>>>
>>> Chain FORWARD (policy DROP)
>>> target     prot opt source               destination
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state
>>> RELATED,ESTABLISHED
>>> ACCEPT     tcp  --  0.0.0.0/0            192.168.1.12         tcp dpt:22
>>> ACCEPT     tcp  --  0.0.0.0/0            192.168.1.12         tcp dpt:80
>>> ACCEPT     all  --  192.168.1.0/24       0.0.0.0/0
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>>
>>> On Mon, Feb 16, 2015 at 8:51 AM, Jim Kinney <jim.kinney at gmail.com>
>> wrote:
>>>
>>>> I'm on my phone at the moment. I'll get on a keyboard and pull data
>>>> shortly.
>>>>
>>>> It does show rules so its running. I'll include the setup rules for
>>>> clarity.
>>>>
>>>> Oh. NetworkManager is not controlling the process at all. In RHEL7 it's
>>>> supposed to be able to do many, many things that could only be done with
>>>> manual tricks. But the new process is far more complicated than doing it
>>>> manually for the simple setup I have.
>>>> On Feb 16, 2015 8:42 AM, "Alex Carver" <agcarver+ale at acarver.net>
>> wrote:
>>>>
>>>>> What are the current rules as listed by iptables -n -L and iptables -n
>>>>> -L -t nat?
>>>>>
>>>>> On 2015-02-16 05:35, Jim Kinney wrote:
>>>>>> I've got a firewall/router running centos 7. I've disabled firewalld
>> and
>>>>>> enabled iptables instead while I learn the new firewalld.
>>>>>>
>>>>>> The box has a WAN nic with 3 IPs. One for itself and the other 2 for
>>>>> other
>>>>>> systems. I'm using nat and have pre and post routing rules to do the
>>>>>> translation.
>>>>>>
>>>>>> Now for the weirdness.
>>>>>>
>>>>>> One works and the other doesn't.
>>>>>>
>>>>>> The rules are identical except for IPs. The rest of the LAN is simply
>>>>> nat
>>>>>> translated outbound. They all work. One server, the :2 on the nic
>> can't
>>>>> get
>>>>>> outside at all if one the static translate. The :1 machine is fine.
>>>>>>
>>>>>> Doing a tcpdump shows ping to WAN gateway going out and returning to
>>>>>> outside nic but it then gets lost in the redirect.
>>>>>>
>>>>>> There are explicit forward rules for needed ports but I opened it to
>> all
>>>>>> ports for the troubled machine.
>>>>>>
>>>>>> It's a new machine that passed a full memtest+ run.
>>>>>>
>>>>>> I'm stumped.

>