[ previous ] [ next ] [ threads ]
 
 From:  "Arnold Cavazos Jr." <abcjr at abcjr dot net>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] smtp delay over 2 firewalls with one bridging
 Date:  Tue, 23 Mar 2004 22:55:49 -0600
I will throw my hat in...

Sendmail trying to do ident lookups?

http://sial.org/howto/sendmail/tips/#s4

--
Arnold Cavazos, Jr.		abcjr at abcjr . net

On Tue, Mar 23, 2004 at 06:31:11PM -0500, Eric Shorkey wrote:
> Just to clear things up for people. I mentioned that the reverse dns on the
> mailserver was very fast in my original message. I was kind of hidden at the
> bottom though. Believe me, I initially thought dns was the problem too, but
> it isn't.
> 
> As for the routing issue, the routing tables aren't doing anything wierd.
> Packets come and go via the same route.
> 
> I'm beginning to think this is going to require me to plug a laptop into the
> dmz with a packet sniffer. I was hoping someone might have ran into this
> already, but it's not looking that way. I'll let everyone know if I find
> anything.
> Cheers!
> 
> ----- Original Message ----- 
> From: "Christiaens Joachim" <jchristi at oce dot be>
> To: "'Eric Shorkey'" <eshorkey at commonpointservices dot com>
> Cc: <m0n0wall at lists dot m0n0 dot ch>
> Sent: Tuesday, March 23, 2004 8:12 AM
> Subject: RE: [m0n0wall] smtp delay over 2 firewalls with one bridging
> 
> 
> > -----Original Message-----
> > From: Eric Shorkey [mailto:eshorkey at commonpointservices dot com]
> > Sent: dinsdag 23 maart 2004 12:23
> > To: m0n0wall at lists dot m0n0 dot ch
> > Subject: [m0n0wall] smtp delay over 2 firewalls with one bridging
> >
> >
> > This is an interesting setup, hopefully someone out there can
> > recreate it and tell me if I'm a loon or not.
> >
> > Here is the problem:
> > I'm experiencing significant connection delays when
> > contacting port 25 of my mailserver. The connection seems to
> > always go through, it just takes about 20 seconds before the
> > connection is established.
> >
> >
> > The setup:
> > I have 5 public ip addresses (it's a /29 ip block). Due to
> > some software I run on most of these ip addresses, I have to
> > firewall #1 in bridging mode between the wan and the lan.
> > Firewall #1 uses one of those public ip addresses for it's
> > WAN port as well, since it insists on having an ip address.
> >
> > The interesting thing is firewall #2. It is using another of
> > those 5 ip addresses on it's wan port. Both of these
> > firewalls' WAN ports are connected to a hub, and that hub is
> > also plugged into my internet provider's equipment. These 2
> > firewalls are protecting the same network, it's purely set up
> > this way because m0n0wall won't route out a bridged interface.
> >
> > My mailserver has multiple network cards, and it's default
> > route is to push out to the public router for internet
> > traffic. One of the network cards is an internet card, and
> > another is for the secured network only.
> >
> > The twist:
> > When connecting to my mailserver using only internal ip
> > addresses, everything runs nice and fast. No delays at all.
> > Only when I'm connecting to the mailserver using the public
> > ip address do I experience the delay.
> >
> > I've tried using proxy arp to force the firewall to publish
> > the ip on the wan card of firewall #1, but that didn't help.
> > (I didn't expect it to, I was grasping at straws.) I'd think
> > it's an arp problem, but it only does this on port 25, so
> > it's very strange. It couldn't really be a dns related issue
> > either. The reverse lookup for ip addresses on the mailserver
> > is very fast, so it's not like the smtp server is waiting for
> > dns. I've even tried setting up rules to specifically block
> > packets destine for firewall #2's ip address from finding
> > their way into the bridged interface on firewall#1. Doesn't
> > help. I've reset the state on both firewalls, that didn't help either.
> >
> > So, I'm kind of at a loss on this one. The setup should work,
> > and it's sane, but I may end up having to change my network
> > design a little to help m0n0wall cope with it. It works for
> > now, the delay is just a little annoying. Figured I'd bounce
> > this one off the mailing list to see what people have to say about it.
> >
> > Cheers!
> > Eric
> 
> Just a guess: do packets get routed/bridged the same way from and to the
> client/server? In other words: do packets follow the same 'road'? This seems
> to give different results for different
> protocols/OS'es/routers/firewalls(state)...
> Some OS'es 'learn' about routes or short-cuts to routers and place these
> 'learned' routes above more general ones, which could add another twist.
> I would look at routing tables and traceroutes and draw a nice diagram :)
> 
> Regards,
> Joachim
> 
> 
> -----------------------------------------------
> MISSION STATEMENT
> -----------------------------------------------
> Oc? enables its customers to manage their documents efficiently and
> effectively by offering innovative print and document management products
> and services for professional environments.
> 
> -----------------------------------------------
> DISCLAIMER
> -----------------------------------------------
> This e-mail message and any attachment are intended for the sole use of the
> recipient(s) named above and may contain information which is confidential
> and/or protected by intellectual property rights.
> Any use of the information contained herein (including, but not limited to,
> total or partial reproduction, communication or distribution in any form) by
> other persons than the designated recipient(s) is prohibited.
> 
> If you have received this e-mail in error, please notify the sender either
> by telephone (0032-2-729.48.11) or by e-mail and delete the material from
> any computer.
> Oce-Belgium/Oce-Interservices is nor responsible for the correct and
> complete transfer of the contents of the sent e-mail, neither for the
> receipt on due time.  This e-mail message does not bring about a contractual
> obligation for Oce-Belgium/Oce-Interservices.
> 
> Thank you for your cooperation.
> 
> For further information about Oce-Belgium/Oce-Interservices please see our
> website at www.oce.be
> 
> -----------------------------------------------
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch

-- 
Arnold Cavazos, Jr.		abcjr at abcjr . net