Go Back   The Scream! > COMPUTER RELATED > PC Security

Reply
 
Thread Tools Display Modes
  #1  
Old 07-January-2004, 13:31
UncleRoger
Guest
 
Posts: n/a
Unhappy IPCop v1.3.0, external aliases, IPs

Does anyone else have any experience using IPCop, public IPs and external aliases?

I've recently put in an IPCop v1.3.0 firewall to sit between our leased line and local network. I'm largely happy with the configuration and have merrily added external aliases to the box and set up port forwarding for email, our two webservers etc. It all works fine.

The problem is that whilst the external aliases function allows me to port forward from the red interface/internet to our LAN on any of our registered public IPs, communication from the server back to the internet goes via the firewall IP.

For example (and I'm just making up the numbers here), I've got public IPs 200.100.50.1 and 200.100.50.2 - the I've configured IPCop's static IP to be 200.100.50.1 and I've added 200.100.50.2 as an external alias. I can then set up a port forwarding rule to forward web traffic on 200.100.50.2 port 80 to my internal webserver on 192.168.0.1. But when 192.168.0.1 sends traffic back the other way, to the external network it appears to come from 200.100.50.1, NOT 200.100.50.2.

AFAIK, this has issues for setting up rules to forward traffic to a Microsoft VPN server using an alias that's different to the firewall IP... and I guess it also prevents adding multiple reverse DNS entries to the if I add another mail server because all SMTP traffic will be sent from the firewall IP.

I'd like to be able to set up some sort of rule that sends outgoing traffic from servers via their external alias IP and not the IP of the firewall. I can't see how to do it via the web interface, so I was wondering whether or not it's possible? IPCop uses iptables, and I'd be happy to manually add a few rules via the root console if this is possible. (I know nothing about iptables, mind you, which is why I'm using something like IPCop to prevent me from having to dig too deep).

In case this is relevant, the firewall is set up with red, orange and green interfaces, but currently everything's configured behind green because the previous firewall we used was red-green only. However, I already have test servers on orange and they appear to behave the same - aliased to one ip but reply with the primary ipcop ip.

Any IPCop/iptables advice would be great.

Thanks in advance,

----UR----
Reply With Quote
  #2  
Old 07-January-2004, 23:44
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

Hi UncleRoger,

Welcome to TS!

I think I know the problem you mean, all internally initiated outbound traffic (e.g. sending mail over SMTP) is using the 'default' IP for the IPCop box.

I am not sure you can do what you need via the GUI in IPCop but it has to be possible to do with a few tweaks,. advice is to post a message to the user list and possibly the dev list to see if anyone can suggest something.

I have been wondering how to do it also so if you find out let us know!

Sil

PS, the NAT will make the outbound replies (e.g. data passed back from an http request) come from the IP that was requested, e.g. if you have

IP A (default)
IP B alias (webserver running here)

a request on the webserver on IP B will see the data come back from IP B but I understand you are asking a different question.
Reply With Quote
  #3  
Old 16-January-2004, 00:40
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

any luck so far?

I have actually got this to work,. I don't know what I've broken yet but it apparently seems to do the job - kinda

lemme know how desperate you are, I will post it eventually anyway once I work out if it really is correct

Sil
Reply With Quote
  #4  
Old 01-February-2004, 12:09
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

well - I have been playing with it for a bit and all I can say is 'it appears to work for me', I don't know if the following idea introduces any security issues.. or will cause your box to break in some interesting way...

ok., ssh into ipcop (version 1.3)

Code:
cd /etc/rc.d
cp rc.firewall rc.firewall_original
vi rc.firewall
look for the 'MASQUERADE' line, it's prolly around line 82 and looks like

Code:
         # Allow IPSec
         /sbin/iptables -A RED -p 47  -i $IFACE -j ACCEPT
         /sbin/iptables -A RED -p 50  -i $IFACE -j ACCEPT
         /sbin/iptables -A RED -p 51  -i $IFACE -j ACCEPT
         /sbin/iptables -A RED -p udp -i $IFACE --sport 500 --dport 500 -j ACCEPT

         # Outgoing masquerading
          /sbin/iptables -t nat -A RED -o $IFACE -j MASQUERADE
the fix we need to do is put specific rules in before the

/sbin/iptables -t nat -A RED -o $IFACE -j MASQUERADE

line,.

something like

Code:
/sbin/iptables -t nat -A RED -s aa.bb.cc.dd -o $IFACE -j SNAT --to-source ee.ff.gg.hh
where aa.bb.cc.dd is the internal IP and ee.ff.gg.hh is one of your owned alias IPs, of course you can add multiple of these snat lines before the 'default' MASQ thing

I am not an iptables expert but I would guess you can futher refine the matching for the snat

file should look something like

Code:
         # Allow IPSec
         /sbin/iptables -A RED -p 47  -i $IFACE -j ACCEPT
         /sbin/iptables -A RED -p 50  -i $IFACE -j ACCEPT
         /sbin/iptables -A RED -p 51  -i $IFACE -j ACCEPT
         /sbin/iptables -A RED -p udp -i $IFACE --sport 500 --dport 500 -j ACCEPT

#silver made me doit http://www.the-scream.co.uk/forums/t11460.html

/sbin/iptables -t nat -A RED -s aa.bb.cc.dd -o $IFACE -j SNAT --to-source ee.ff.gg.hh

         # Outgoing masquerading
          /sbin/iptables -t nat -A RED -o $IFACE -j MASQUERADE
some referances so you can see where I went wrong

http://www.siliconvalleyccie.com/lin...m#_Toc57743584

http://www.mandrakesecure.net/en/doc...inuxdoc-6.html

once you are happy reboot the box,. if it breaks then put back the original file or re-install IPCop..

Sil
Reply With Quote
  #5  
Old 01-February-2004, 17:22
xraided
Guest
 
Posts: n/a
Default

Hi Silver. I saw your post on the ipcop-user mailing list, and wanted to let you know I'm having the same problems with IPCOP, however, I have yet to find a solution. I will try yours sometime today, and will let you know what I come up with. I had actually just posted to the ipcop-user mailing list a few days ago with my problem, but nobody gave me a reply I put a copy of the post here: http://www.xraided.net/~kyle/ipcop-user.txt (It just explains the problems I was having). Thanks for the suggestions, I had been trying to find a solution for quite some time.



-Kyle
Reply With Quote
  #6  
Old 01-February-2004, 18:01
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

Hi Kyle,

I am hopeful someone on the list can confirm whether using SNAT in this way is correct, it looks ok to me but I would like other opinions before being in any way confident!

I confess I did see your request on the list but unfort no iptables gurus came forward to offer any advice, I guess I will re-post my question to the dev list incase anyone there knows.

One scenario (perhaps not that likely) that I'm not sure if the SNAT thing will break is:

IPcop with 2 i'net IPs (A) and (B)

internally initiated / outbound tcp connections (e.g. smtp outbound) from internal address (Bi) have their source IP set to (B) on the way out,. this is fine and what we are aiming to do.

but what happens if the packets travelling back from (Bi) are part of a connection that was initiated from a request through external IP (A) will these get their source IP set to (B) and therefore break things?

I am guessing the NAT table handles this and therefore it's not a problem but I don't actually know. It's not an issue for me since on my setup I don't have inbound requests on (A) that get to (Bi).

Let us know how you get on, plse!

Sil

PS, welcome to TS!
Reply With Quote
  #7  
Old 01-February-2004, 23:48
xraided
Guest
 
Posts: n/a
Default

Dude, I love you.

Kidding aside, it works!!! Now, If only there was an "easy" way to configure a CGI to add this functionality to the IPCop Web-GUI.... I'd be more than willing to give it a whirl, however, I don't have much knowledge in the IPTABLES area.... Temporarily, I'm going to put one of my not-so-important machines behind this setup (with 3 alias IP's), and see how it works (I have 32 IP's on 3 different machines, but I figured we should take baby steps at first, and see if anything breaks). I'll keep you posted over the next week or so. Thanks a ton dude.

Maybe there is some way we could request this functionality to be put in IPCop 1.4.0? As I said earlier, I'd be more than willing to contribute some CGI scripts if need be. With this functionality, this makes IPCop one step closer to professional solutions....


-Kyle


EDIT: Here's a link to what my rc.firewall addition would be... http://www2.klmhosting.net/~kyle/ipcop-static-nats.txt


-Kyle

Last edited by xraided; 02-February-2004 at 05:02.
Reply With Quote
  #8  
Old 05-February-2004, 18:02
ADCGROUP
Guest
 
Posts: n/a
Default

Maybe some of you guys can help me out.

I just set up an IPCop box and am having trouble viewing websites in the ORANGE zone.

I have a T1 coming into a Cisco 1720, then to a switch, then to my IPCop box RED if.

From my IPCop box, I have the ORANGE if connected to a switch which connects to a Cobalt RaQ3 webserver.

I have the GREEN if connected directly to a PC via a crossover cable.

I have tried configuring aliases, port forwarding, and Ext. Service Access so many different ways, I can't remember them all and have yet to be able to access the websites from an 'outside' IP.

At the moment, I have it where I can pull up the website on the PC that is directly connected to the IPCop box. I have accomplished that with the following settings:

External Aliases 123.123.123.7 and 123.123.123.20 (changed, of course) represent the public IPs of my 2 websites.

Port forwarding is set for TCP 123.123.123.7:80 >> 10.10.10.7:80 and TCP 123.123.123.20:80 >> 10.10.10.20:80

I've cleared out all other alias, port, and ext. service access settings.

With the above minimal settings, I can pull up the websites from the PC connected directly to the IPCop box (both by IP and name).

No other settings I have ever tried have allowed access to the websites from the 'outside'.

Here are some settings:
RED=123.123.123.254
ORANGE=10.10.10.1
GREEN=192.168.0.1

The DNS on my Cobalt RaQ points to the PUBLIC IPs of the websites (e.g. www.myfirstdomain.com=123.123.123.7, www.myseconddomain.com=123.123.123.20)


I'm pulling my hair out, so I've got to go back to the basics.

Given the information above, how do I set my box up to allow 'outside' traffic to view my websites in the ORANGE zone?

Thanks in advance!

Duane
Reply With Quote
  #9  
Old 05-February-2004, 21:16
xraided
Guest
 
Posts: n/a
Default

It sounds like you have it all setup correctly: All you need to do is have an alias and portforward defined.

In your case, You need 2 aliases on the Red interface:

123.123.123.7
123.123.123.20

Then, two portforwards:

123.123.123.7:80(TCP) ==> 10.10.10.7:80(TCP)
123.123.123.20:80(TCP) ==> 10.10.10.20:80(TCP)


Now, if you still don't get information to the DMZ zone... Make sure you have your Cisco Router setup correctly.

At the moment, I have it where I can pull up the website on the PC that is directly connected to the IPCop box.
If that is the case, and you are using www.mydomain.com to access the website (and www.mydomain.com doesn't resolve to an internal IP), it should be working.
Reply With Quote
  #10  
Old 05-February-2004, 22:16
ADCGROUP
Guest
 
Posts: n/a
Default

Ok, when I ping www.myfirstdomain.com, it resolves to 123.123.123.7 (public ip) and I get answers on the pings. Same thing with www.myseconddomain.com.

I have no other rules than the following:

PORT FORWARDING
123.123.123.7:80(TCP) ==>10.10.10.7:80(TCP)
123.123.123.20:80(TCP)==>10.10.10.20:80(TCP)

EXTERNAL ALIASES
123.123.123.7
123.123.123.20 (both enabled)

NO Web Proxy, DMZ Pinholes, or Dynamic DNS settings; DHCP is enabled, but just with the default info IPCop had (Primary DNS 172.24.150.1 for GREEN network, etc.)

VPN is NOT enabled
NO Dialup or Modem configs
SSH is enabled
Snort is enabled
In the Information section, I have everything but VPN and Web Proxy RUNNING

I still can only pull up the websites on the PC connected to the IPCop box. [puzzled]

My Cisco 1720 is running a bare config with just enough info to route the T1 - nothing else.
Reply With Quote
  #11  
Old 05-February-2004, 22:32
xraided
Guest
 
Posts: n/a
Default

How do you know systems outside the IPCop network can't access the DMZ machines?
Reply With Quote
  #12  
Old 05-February-2004, 23:02
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

goto http://www.rexswain.com/httpview.html and put the external IPs into the bit where it says http:// use http://123.123.123.7

ignore the dns for now, just try to get them accessed from external via their IPs. IPCop is doing NAT so it's quite possible you won't be able to access the boxes using their external IPs while sat inside the NAT

Sil

PS,. "external service access" is to allow outside to access IPCop box itself - so don't have anything in there (cept for the default 113 TCP for ident is ok)
Reply With Quote
  #13  
Old 05-February-2004, 23:06
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

also - while using the green box - can you access

http://10.10.10.7

i.e. the webserver via it's internal IP while sat inside the NAT?

Sil
Reply With Quote
  #14  
Old 06-February-2004, 03:42
ADCGROUP
Guest
 
Posts: n/a
Default

OK, I have just displayed my n00b-ness a bit.

I can view the websites from an outside IP. I have another network coming off the T1 on a Linksys router. I thought that would be enough to separate them, but apparently not. I'm still a little puzzled by that... but then I haven't been thinking clearly lately!

The website's working, but I can't get a login for siteadmin or admin (www.mydomain.com/admin or /siteadmin for the Cobalts) from the outside. The Cobalt uses port 81, but IP cop won't let me open port 81 ("Destination port is reserved for Ipcop use only: 81"). I can get to it from the PC connected to the IPCop box if I type in "http://10.10.10.7/siteadmin". Here's the kicker - only when I am logged into IPCop in another browser window.

Any idea why that is?

Thanks guys!
Reply With Quote
  #15  
Old 06-February-2004, 10:20
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

The Cobalt uses port 81 - can you change this?

ipcop expects port 81 to be for it's http connection..

it's possible to change this (by hacking it) but I am not sure it is recommended,. if you have to do it take a look at (search for 81)

/home/httpd/cgi-bin/portfw.cgi
and
/etc/httpd/conf/httpd.conf

but there might be other things you would need to change, I've not tried this and any risk is in your hands!

I can get to it from the PC connected to the IPCop box if I type in "http://10.10.10.7/siteadmin". Here's the kicker - only when I am logged into IPCop in another browser window
I presume that once you connect to
http://10.10.10.7/siteadmin your browser gets sent some kind of re-direct to go to http://10.10.10.7:81/?? perhaps - not that it makes much difference..

I can't think of a reason for it not to work (or only work when logged in to ipcop).. what happens exactly when it 'doesnt work' i.e. what kind of response do you get?

Sil
Reply With Quote
  #16  
Old 08-February-2004, 18:06
ADCGROUP
Guest
 
Posts: n/a
Default

Thanks for the help Silver! I've got it working at the moment - I think the way I want it to.

editing the portfw.cgi and httpd.conf did the trick for the Cobalt.

I've got a week or so of testing ahead to make sure that it withstands everything well.

I only have one small issue left - and it's not a dealbreaker.

I have the T1 coming in to my a switch that feeds 3 zones at the moment (soon to be 2). Coming off the switch, I've got my IPCop box, the servers remaining that are left out in the cold at the moment, and a private network running off a Linksys broadband router. My ultimate goal is to leave the Linksys in place, because I'm feeding wireless off of it and doing games, communications, etc. with those machines that would be heavily complicated by putting it behind the firewall. The linksys does a little to protect them, and they're not that critical anyway. I could use ZoneAlarm or Black Ice to further protect them, but may not bother [suggestions?].

At any rate, Here's the situation: My computers that are behind the Linksys router can't access any webpages on the server behind the firewall. The PCs connect to the Linksys, which in turn connects to the switch off the T1, which is also connected to the Firewall which connects to the webserver. (confused?) They will connect just fine to the webservers that are outside of the firewall on the same switch that the Linksys and firewall are on.

What's up w/ that? I can connect from 'outside' fine now, and I wouldn't think the Linksys network would fall under any rules of the Firewall just like the webservers outside of the Firewall (BTW, their websites are freely available to the 'outside' as well as PCs in the Linksys network).

Just a puzzler...

Thanks again!
Reply With Quote
  #17  
Old 08-February-2004, 18:23
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

umm - kinda hard to understand what you have setup w/o seeing a picture

in general,. PCs which are behind a NAT may have trouble connecting to PCs behind the same NAT when addressed via their external (internet) IP.. the general way round this is to address PCs inside your network via their internal IPs.. simple way is to add entries into your 'hosts' file so the external names resolve to internal IPs..

there's other neater ways - like using an internal DNS zone or using IP cop to do the DNS, you just put the external names into IPcops hosts file

Sil
Reply With Quote
  #18  
Old 08-February-2004, 20:33
ADCGROUP
Guest
 
Posts: n/a
Default

Here's what my network currently looks like:



Hope that helps.

The PC's behind the Linksys can't see websites behind the firewall, although 'outside' machines can. The private IPs behind the Linksys are on a different subnet than the GREEN zone subnet in case that makes any difference. Physically, it seems to me that they're separate networks. Each network is only looking to its own router (or Firewall) for internet access, so only the IPCop box and Linksys share any commonality and that only in their source for internet.

There must be some kind of issue with the Linksys (123.123.123.190) being on the same subnet as the RED Zone NIC (123.123.123.254) as they're the ones ultimately making the exchange on behalf of the machines for which they route.

Now, the PC you see behind the IPCop box, has no trouble accessing websites on the server that is also behind the IPCop box using either the public ip or fq Domain Name. (GREEN Zone to ORANGE Zone)

Can I uses 'hosts' to define information across different private networks?
Reply With Quote
  #19  
Old 08-February-2004, 20:47
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

Can I uses 'hosts' to define information across different private networks? - yes

one simple way to fix it is to put the linksys on the green part behind ipcop? (Ipcop 1.4 will have another zone called blue for w/less or another network bit like another green i/f I think).

I'd put the linksys on another network inside green,. with a different netmask and let the linksys route between the w/less part and the green i/f on ipcop?

pic helps, but.. is hard to see whats going on w/o having the ips/masks for each part (can make them up / change them so long as they are representative of what's there)

Sil

PS, you can try tracert / traceroute between the PCs on linksys and orange which might show where the packets are getting messed up?
Reply With Quote
  #20  
Old 08-February-2004, 20:48
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default

PS, can you get to the boxes in orange using their internal IPs (from linksys and / or green) ?
Reply With Quote
  #21  
Old 09-February-2004, 01:50
ADCGROUP
Guest
 
Posts: n/a
Default

Thanks for the help Sil, I went ahead and put the Linksys behind the Firewall, disabled DHCP on the Linksys and connected directly to the switch rather than the router (WAN) port. I configured the Linksys for an IP on the GREEN subnet that was out of the IPCop DHCP range, and Voila! (Basically, I'm just using the Linksys as an Access Point now and none of the routing)

It still puzzles me, but that lesson will have to wait for another day. I didn't want the wireless-connected PCs to be routed so many times since we play online games, etc. on them from time to time.

For the benefit of anyone following now or in the future, here's a brief status. As of now, I only have a couple of servers outside the firewall (They'll be moved once I'm sure DNS is working right). Everything else is behind the IPCop Firewall box in either the ORANGE (DMZ) Zone or GREEN (LAN) Zone.

RED=123.123.123.254 (Public IP)
-----Connected via switch/Cisco 1720 (123.123.123.1) to T1 internet source
------------IP Aliasing for websites:
------------123.123.123.7 - forwarded to 10.10.10.7 in DMZ
------------123.123.123.20 - forwarded to 10.10.10.20 in DMZ

ORANGE=10.10.10.1 (Zone=10.10.10.0/24 - Private IPs)
-----Cobalt Webserver hosting websites and DNS at:
----------10.10.10.7 www.myfirstdomain.com (123.123.123.7 public IP)
----------10.10.10.20 ns1.myseconddomain.com (123.123.123.20 public IP)
----------** DNS pointing to PUBLIC IP addresses **

GREEN=192.168.0.1 (Zone=192.168.0.0/24 - Private IPs)
------PC_1=192.168.0.100 (DHCP)
------PC_2=192.168.0.101 (DHCP)
------PC_3=192.168.0.102 (DHCP)
------Linksys WiFi=192.168.0.50 (Static)
------------PC_4=192.168.0.103 (DHCP)
------------PC_5=192.168.0.104 (DHCP)
------------PC_6=192.168.0.105 (DHCP)
------LAN Server=192.168.0.250 (Static)


PORT FORWARDING
--------------------------
Forwarding TCP ports 21, 25, 80, 81, 110 for 123.123.123.7 =>10.10.10.7

Forwarding TCP ports 53, 81 for 123.123.123.20=>10.10.10.20

----------------------------

Do I need any ports other than 53 for DNS?

DNS is really the last link of the chain. I still have one DNS server outside the firewall. I'll know if everything works once I move it behind.

Thanks everyone!
Reply With Quote
  #22  
Old 14-July-2009, 19:30
p3rlphr33k
Guest
 
Posts: n/a
Default Re: IPCop v1.3.0, external aliases, IPs

Sorry to revive an very old thread..but this is exactly the situation i am in, the new twist both servers are virtual hosts with more than 1 domain.

I Can configure everything according to this thread and only get a generic welcome screen as if the http header isnt passing to the server any ideas?
Reply With Quote
  #23  
Old 15-July-2009, 08:29
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default Re: IPCop v1.3.0, external aliases, IPs

think this is an apache question,. what version are you using?
Reply With Quote
  #24  
Old 15-July-2009, 09:34
p3rlphr33k
Guest
 
Posts: n/a
Default Re: IPCop v1.3.0, external aliases, IPs

Here are the server's software setup:
Apache 2.2.6, PHP 5.2.4, MySQL 5.0.45, Postfix, BIND9, POP3/IMAP

Was running it behind a single IP with, IPCop was forwarding all port 80 requests to single server running win2003 with Octagate reverse proxy.

network was picking up traffic and started to slow way down so i leased 5 statics from my isp. now i have all statics configured as alias IP's port forwarding to the corresponding server in the DMZ e.g.
24.x.x.229=>10.0.0.29
and
24.x.x.230=>10.0.0.30

Thats all fine and dandy... but IPCop's NAT destorys the HTTP Header that calls the correct domain.
I have modfied the replies with the somthing similar to this:

/sbin/iptables -t nat -A RED -s 10.x.x.29 -o $RED -j SNAT --to-source 24.x.x.229
/sbin/iptables -t nat -A RED -s 10.x.x.30 -o $RED -j SNAT --to-source 24.x.x.230

I can enter a URL from an external addess, an it replies with a generic "Shared IP" or "Fedora Test Page" I can run lynx --dump whatismyip.com and verify alias is working...

so.. i think i covered most everything but the packet its self since thats how the virtual server operates what do you think?
Reply With Quote
  #25  
Old 15-July-2009, 21:18
p3rlphr33k
Guest
 
Posts: n/a
Default Re: IPCop v1.3.0, external aliases, IPs

I came back to check for replies, noticed i never gave you th IPcop version.. appologies
IPCop V1.2.40
Reply With Quote
  #26  
Old 15-July-2009, 21:26
p3rlphr33k
Guest
 
Posts: n/a
Default Re: IPCop v1.3.0, external aliases, IPs

I think i need to add an IPTable to to check source address, port and forward full packet to server to get the correct response.. but I am horrible with iptables I guess rather than looking at my issue at large, this is what i would like to do with IPtables:
check alias IP if it matches one on the defined:
24.x.x.228, 24.x.x.229, 24.x.x.230
and matches port:
80, 81
forward packet to internal address associated with alias IP..

Can anyone help me with this iptable??

...I must say this single thread has been the greatest help to me I have found yet on the internet! Thanks for your replies
Reply With Quote
  #27  
Old 16-July-2009, 00:49
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default Re: IPCop v1.3.0, external aliases, IPs

hang on

ipcop NAT (well any / most NAT) will not mess with http header information, all it does is network address translation to move the packets between the networks (i'net and DMZ etc)

I would remove that SNAT stuff - it is not what you need,. because all http traffic will be initiated from outside of the server (i.e. server replies to http requests) and have the correct source IP (so SNAT will/should be ignored in this case)

the only reason to use the SNAT stuff is if you have smtp or some other type of outbound traffic that requires a specific source IP set

the issue is very likely an apache config issue,. have you tried to access the http server from another server within the DMZ or if you have a green network to use that to check server config

IPCop was forwarding all port 80 requests to single server running win2003 with Octagate reverse proxy
- have you removed this,. proxy is very likely to mess with http headers and might be confusing things

my advice - remove the SNAT stuff - is not required (at least not for normal http/apache stuff like this) and then check the apache config,. you can send page requests from i'net using http://www.rexswain.com/httpview.html

check the server http logs - make sure the request is hitting the server and see if any errors or such display
Reply With Quote
  #28  
Old 16-July-2009, 01:05
p3rlphr33k
Guest
 
Posts: n/a
Default Re: IPCop v1.3.0, external aliases, IPs

i can connect the web server by configuring a static directly to the NIC, and it works just fine. As soon as i put it behind the fire wall it starts returning generic page. as if i were requesting the IP not the domain. (named based virtual host)

here are the static IP's:
226,227,228,229,230

IPCop = 226 rest are alias on RED
227 is extra
sql server = 228
web1 = 229
web2 = 230

when i would request a site it would time out.
so i ran: lynx --dump http://whatismyip.com
on server, it was showing 226(firewall)
not 229
so i assumed it was doing this:

REQUEST for domain->ALIAS IP 229->internal IP->REPLY->226->no client on 226

the SNAT corrected the reply to 229
and now i get generic "welcome - your sever has been setup" page

I will pull the log once i get home (working :P)

and yes, the proxy has been removed, the whole reason this came about lol

I have considered changing the apache config to listen on alias IP 229.. would this help?
Reply With Quote
  #29  
Old 16-July-2009, 01:14
silver's Avatar
silver silver is offline
 
Join Date: Apr 2001
Location: Bournemouth, UK
Posts: 12,177
Default Re: IPCop v1.3.0, external aliases, IPs

I am not an apache expert so I will not try to understand what you have setup exactly

think of it this way,. lets say you had no firewall - server was direct on the i'net

123.123.123.230 - it's config'd for that and works fine (I think this is what you say)

now,. we wish to put it behind a firewall,. so we remove from it an i'net address and instead put it into private space

192.123.123.230 - now what we have done is make it answer / believe it is 192.123.123.230 - any config you had on the server (especially apache config!) that relates to the external (internet) address 123.123.123.230 now requires to instead be config'd to talk about the DMZ related address 192.123.123.230 - see?

..

now on the SNAT - forget SNAT - it is misleading and will serve to confuse,. now you want your server on 192.123.123.230 to answer i'net queries - so on IPcop we want an alias for the external 123.123.123.230 - on that we then add a port forward - port 80 on 123.123.123.230 requires to be forward to port 80 on 192.123.123.230

now it will all work,. remember we must check from outside the network - put in domain name / website via http://www.rexswain.com/httpview.html
Reply With Quote
  #30  
Old 16-July-2009, 01:36
p3rlphr33k
Guest
 
Posts: n/a
Default Re: IPCop v1.3.0, external aliases, IPs

right, now web server is configured on: 10.0.0.29

226-firewall
229-alias
port forward 299 on 80 to 10.0.0.29
request time out without SNAT??

adde SNAt again, get welcome page
Reply With Quote
Reply

Tags
123, birthday, broadband, cable, connection, dhcp, dns, email, forward, hacking, happy, home, internet, isp, line, mail, make, nat, network, offer, orange, port, public, security, smtp, talk, web, wireless, zone, zonealarm

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:25.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Copyright 1999-2014 The Scream!