We're doing NAT. We just don't need additional "NAT rules" according to the Untangle definition of them. We should have just been using the system-created rules and not creating additional rules of our own.
On Thu, Aug 7, 2014 at 3:01 PM, Paul Boniol <[email protected]> wrote: > Something will be needing to do NAT since you are using 192.168. > addresses. Whether that's your firewall or your ISP connection(s). > > Paul > > > On Thu, Aug 7, 2014 at 2:49 PM, Chris McQuistion <[email protected]> > wrote: > >> Mystery solved! >> >> I called Untangle and got some help from them. (I'm paying for this >> thing, so I ought to get some tech support, right?) >> >> My port forwarding and everything was pretty straightforward and nothing >> wrong there. >> >> Untangle has the ability to create static routes, but they also have "NAT >> rules" where you can set up something very similar to a static route, but >> it also re-writes the packets on the way out of the network to strip out >> any internal IP information. We had "NAT rules" set up and didn't really >> need them. Once the "NAT rule" was disabled, /var/log/messages starting >> showing the correct external IP address when I would connect in, from the >> off-site server. >> >> It's weird that it only affected our RHEL 5 server and none of the >> others. The NAT rule only re-writes outgoing packets and not incoming >> packets, so the Untangle guy couldn't quite figure out why it would affect >> an incoming SSH connection like this, but the fact is that it did and the >> NAT rules really weren't needed. >> >> Chris >> >> >> On Thu, Aug 7, 2014 at 1:32 PM, Sabuj Pattanayek <[email protected]> >> wrote: >> >>> the interesting part is that it only seems to be happening on his RHEL5 >>> system and not on the other ones. >>> >>> >>> On Thu, Aug 7, 2014 at 11:48 AM, Tilghman Lesher <[email protected]> >>> wrote: >>> >>>> None of those packages would affect how packets are logged. At this >>>> point, I'd do a tcpdump on the external interface on that particular >>>> server, then pull up the dump in Wireshark. That should tell you >>>> whether the packets are being rewritten incorrectly by the firewall or >>>> if the server is simply doing something strange. You shouldn't have >>>> to look any further than the IP header to verify the >>>> source/destination address. >>>> >>>> On Thu, Aug 7, 2014 at 11:27 AM, Chris McQuistion >>>> <[email protected]> wrote: >>>> > Interesting thought. >>>> > >>>> > The firewall rules are the same for this server as all the other >>>> servers and >>>> > none of the other servers are showing this anomaly in their logs. >>>> > >>>> > I went ahead and deleted the rule, then recreated it, then tested >>>> again. >>>> > Same results. >>>> > >>>> > The day that I started getting these weird entries was the first day >>>> that >>>> > server was logged into from offsite and right after installing some >>>> yum >>>> > updates. I looked through the Logwatch emails and these yum updates >>>> > correspond to that same day. Any chance one of these could change >>>> the way >>>> > that this information is being logged? I can tail /var/log/secure >>>> and watch >>>> > it log the wrong IP address when I login from home. >>>> > >>>> > Packages Updated: >>>> > nss-3.15.3-7.el5_10.i386 >>>> > httpd-manual-2.2.3-87.el5_10.x86_64 >>>> > 1:mod_ssl-2.2.3-87.el5_10.x86_64 >>>> > nspr-4.10.6-1.el5_10.i386 >>>> > nss-tools-3.15.3-7.el5_10.x86_64 >>>> > firefox-24.7.0-1.el5_10.i386 >>>> > nss-3.15.3-7.el5_10.x86_64 >>>> > httpd-2.2.3-87.el5_10.x86_64 >>>> > firefox-24.7.0-1.el5_10.x86_64 >>>> > nspr-4.10.6-1.el5_10.x86_64 >>>> > >>>> > >>>> > >>>> > >>>> > On Thu, Aug 7, 2014 at 10:42 AM, Tilghman Lesher < >>>> [email protected]> >>>> > wrote: >>>> >> >>>> >> On Wed, Aug 6, 2014 at 3:20 PM, Chris McQuistion >>>> >> <[email protected]> wrote: >>>> >> > This is a weird problem. >>>> >> > >>>> >> > I get the daily logwatch emails from our various servers and one >>>> of the >>>> >> > things that I eyeball on a regular basis is the "Users logging in >>>> >> > through >>>> >> > sshd". I like to make sure that I don't see any logins from IP >>>> >> > addresses >>>> >> > that I don't recognize (as well as failed login attempts.) >>>> >> > >>>> >> > We changed our firewall about a week and a half ago, over to >>>> Untangle. >>>> >> > This >>>> >> > has had no negative affect on any of the usual behavior except for >>>> one >>>> >> > of >>>> >> > our servers, a database server running RHEL 5.X (64 bit, fully up >>>> to >>>> >> > date.) >>>> >> > >>>> >> > On this one system, I'm now seeing the following line in it's daily >>>> >> > Logwatch >>>> >> > email: >>>> >> > >>>> >> > 192.168.1.254 (firewall.watkins.edu): 2 times >>>> >> > >>>> >> > That IP address is the firewall, itself. The firewall is NOT >>>> actually >>>> >> > logging into this server. My Linux box at home is logging in via >>>> SSH, >>>> >> > every >>>> >> > day, to run backups. In the past, and with every other server >>>> that I >>>> >> > remotely backup via SSH, every day, the Logwatch email reflects >>>> the IP >>>> >> > address of my cable modem at home. >>>> >> > >>>> >> > In this one case, this server shows 192.168.1.254 (the firewall) >>>> as the >>>> >> > source IP address instead of the "real" source IP address. >>>> >> > >>>> >> > Port forwarding to this server is set up exactly the same way as >>>> all the >>>> >> > other servers. The backup program I'm running at home (dirvish) >>>> >> > connects to >>>> >> > this server, just like the other servers. >>>> >> > >>>> >> > The only variable that has changed is the firewall and possibly >>>> some >>>> >> > recently-run yum updates. The only unique thing about this >>>> server, is >>>> >> > that >>>> >> > it is our only RHEL 5 server. We also have a RHEL 6 server and >>>> several >>>> >> > CentOS 5/6 servers. >>>> >> > >>>> >> > Any ideas? >>>> >> >>>> >> I suspect a difference in how your firewall is set up to forward >>>> those >>>> >> packets. I'd look at the underlying iptables commands, not the >>>> >> frontend information. It sounds like the firewall is rewriting the >>>> >> source address on those packets. >>>> >> >>>> >> -- >>>> >> Tilghman >>>> >> >>>> >> -- >>>> >> -- >>>> >>>> -- >>>> Tilghman >>>> >>> > -- > -- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "NLUG" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en --- You received this message because you are subscribed to the Google Groups "NLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
