[Searche gebruikt] Forward probleem

[Verwijderd]

Hai allemaal,

Ik probeer op mijn linux machine port 1494 via iptables te forwarden naar ip 10.0.0.1 (Intern ip) maar ik krijg het niet voor elkaar..

iptables -t nat -A PREROUTING -p tcp --dport 1494 -i eth1 -j DNAT --to 10.0.0.1:1494
iptables -t nat -A PREROUTING -p udp --dport 1494 -i eth1 -j DNAT --to 10.0.0.1:1494

Dit werkt niet.
Ik snap er echt helemaal niks meer van. ik heb overall gezocht maar kan geen oplossing vinden.
Op port 1494 zit een Citrix Terminal server.. Wie o wie kan mij een duw in de goeie richting geven..

[Verwijderd]

echt heel wazig dit... weet het echt niet meer...

[Verwijderd]

ff uit een script gehaald, de regels van jou staan er bijna letterlijk in, maar er staat nog iets voor:
iptables -I FORWARD -p tcp -d 10.0.0.1 --dport 1494 -j ACCEPT
iptables -I FORWARD -p udp -d 10.0.0.1 --dport 1494 -j ACCEPT
Dit zal er voor zorgen dat je firewall verkeer van dat adres op de poort accepteert.

[Verwijderd]

uuuuuh...

dan wordt het dit...

iptables -I FORWARD -p tcp -d 10.0.0.1 --dport 1494 -j ACCEPT
iptables -I FORWARD -p udp -d 10.0.0.1 --dport 1494 -j ACCEPT

iptables -A INPUT -i eth1 -p tcp --dport 1494 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 1494 -j ACCEPT

Maar dit werkt dus ook gewoon niet ....

[Verwijderd]

Euhm je verkeer komt ook via eth1 binnen
En return verkeer mag geforward worden door de machine (of gemasqueraded).?

janjanjansen: dat is niet nodig; de PREROUTING zorgt er al voor

[Verwijderd]

INPUT geldt sowieso al niet.
Dat is alleen geldig voor verkeer dat voor de machine zelf bestemd is.

[Verwijderd]

Op maandag 12 november 2001 01:15 schreef nelske het volgende:
Euhm je verkeer komt ook via eth1 binnen
En return verkeer mag geforward worden door de machine (of gemasqueraded).?

janjanjansen: dat is niet nodig; de PREROUTING zorgt er al voor

Internet verkeer komt binnen op eth1 en netwerk zit op eth0.

Het lijkt me dat verkeer ook terug moet van 10.0.0.1 het is een terminal server. Net zo iets als pc anywhere

[Verwijderd]

En het verkeer van 10.0.0.1 wordt via de POSTROUTING chain ook weer ge-SNAT (of MASQUERADEd) ?

Wat zegt tcpdump precies?
Verschijnt het in /proc/net/ip_conntrack?

[Verwijderd]

als ik een port scan via een andere linux bak doe. Dan zie ik ook niet dat port 1494 filtered is.. En dat moet volgens mij ook zo zijn


/etc/rc.d/rc.flush
/sbin/modprobe ip_tables
/sbin/modprobe iptable_nat
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -I FORWARD -p tcp -d 10.0.0.1 --dport 1494 -j ACCEPT
iptables -I FORWARD -p udp -d 10.0.0.1 --dport 1494 -j ACCEPT

iptables -A INPUT -i eth0 -p tcp --dport 1494 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 1494 -j ACCEPT

/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.1/24 -o eth0 -j MASQUERADE

Dit is wat ik nu heb

[Verwijderd]

Maak er eens hetvolgende van:

code:

/etc/rc.d/rc.flush
/sbin/modprobe ip_tables
/sbin/modprobe iptable_nat
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A PREROUTING -t nat -p tcp -i eth1 --dport 1494 -j DNAT --to 10.0.0.1:1494
iptables -A PREROUTING -t nat -p udp -i eth1 --dport 1494 -j DNAT --to 10.0.0.1:1494

iptables -A POSTROUTING -t nat -o eth1 -s 10.0.0.1/32 -j MASQUERADE

Bovenstaande moet gegarandeerd werken.

[Verwijderd]

Op maandag 12 november 2001 01:32 schreef nelske het volgende:
Maak er eens hetvolgende van:

code:

/etc/rc.d/rc.flush
/sbin/modprobe ip_tables
/sbin/modprobe iptable_nat
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A PREROUTING -t nat -p tcp -i eth1 --dport 1494 -j DNAT --to 10.0.0.1:1494
iptables -A PREROUTING -t nat -p udp -i eth1 --dport 1494 -j DNAT --to 10.0.0.1:1494

iptables -A POSTROUTING -t nat -o eth1 -s 10.0.0.1/32 -j MASQUERADE

Bovenstaande moet gegarandeerd werken.

Okee hij is nu gefilterd.. Zie dat ik eth op 0 had staan.. etc etc.. okee dat snap..

Accepteer geen connectie's dat ding... als ik redir gebruik werkt het wel... (alleen dat is echt buggie) dus aan me client kant zit het wel goed.. Hmmmzzz...

[Verwijderd]

Op maandag 12 november 2001 01:39 schreef WilcoRADIO het volgende:

[..]

Okee hij is nu gefilterd.. Zie dat ik eth op 0 had staan.. etc etc.. okee dat snap..

Accepteer geen connectie's dat ding... als ik redir gebruik werkt het wel... (alleen dat is echt buggie) dus aan me client kant zit het wel goed.. Hmmmzzz...

Yep je wil alleen verkeer maskeren dat van 10.0.0.1 komt en naar buiten gaat via eth1 (-o eth1)
Verder heb ik het subnetmasker even in 32 verandert, zodat het alleen voor 10.0.0.1 geldt; als je meerdere hosts wil masqueraden dan zul je uiteraard dat subnetmasker naar smaak aan moeten passen.

Maar welke machine accepteert geen connecties ?
Wat geeft de output van de volgende commando's?

code:

iptables -L
iptables -L -t nat
route -n
tail /proc/net/ip_conntrack

[Verwijderd]

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vos rc.d]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:ica to:10.0.0.1:1494
DNAT udp -- anywhere anywhere udp dpt:ica to:10.0.0.1:1494

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- sv-001 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vos rc.d]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
212.58.172.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.58.172.1 0.0.0.0 UG 0 0 0 eth1


tcp 6 432000 ESTABLISHED src=212.58.172.94 dst=212.58.172.50 sport=3355 dport=22 src=212.58.172.50 dst=212.58.172.94 sport=22 dport=3355 [ASSURED] use=1
udp 17 4 src=10.0.0.1 dst=10.0.0.255 sport=520 dport=520 [UNREPLIED] src=10.0.0.255 dst=10.0.0.1 sport=520 dport=520 use=1
tcp 6 70 SYN_SENT src=212.58.172.94 dst=212.58.172.50 sport=52749 dport=180 [UNREPLIED] src=10.0.0.2 dst=212.58.172.94 sport=110 dport=52749 use=1
tcp 6 112 TIME_WAIT src=212.58.161.131 dst=212.58.172.50 sport=4049 dport=25 src=212.58.172.50 dst=212.58.161.131 sport=25 dport=4049 [ASSURED] use=1
unknown 2 582 src=192.168.100.1 dst=224.0.0.1 [UNREPLIED] src=224.0.0.1 dst=192.168.100.1 use=1
tcp 6 52 TIME_WAIT src=212.58.161.131 dst=212.58.172.50 sport=4046 dport=25 src=212.58.172.50 dst=212.58.161.131 sport=25 dport=4046 [ASSURED] use=1
udp 17 172 src=127.0.0.1 dst=127.0.0.1 sport=1025 dport=53 src=127.0.0.1 dst=127.0.0.1 sport=53 dport=1025 [ASSURED] use=1
udp 17 14 src=10.0.0.1 dst=10.0.0.255 sport=138 dport=138 [UNREPLIED] src=10.0.0.255 dst=10.0.0.1 sport=138 dport=138 use=1

[Verwijderd]

Op maandag 12 november 2001 01:47 schreef WilcoRADIO het volgende:
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vos rc.d]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:ica to:10.0.0.1:1494
DNAT udp -- anywhere anywhere udp dpt:ica to:10.0.0.1:1494

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- sv-001 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@vos rc.d]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
212.58.172.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.58.172.1 0.0.0.0 UG 0 0 0 eth1


tcp 6 432000 ESTABLISHED src=212.58.172.94 dst=212.58.172.50 sport=3355 dport=22 src=212.58.172.50 dst=212.58.172.94 sport=22 dport=3355 [ASSURED] use=1
udp 17 4 src=10.0.0.1 dst=10.0.0.255 sport=520 dport=520 [UNREPLIED] src=10.0.0.255 dst=10.0.0.1 sport=520 dport=520 use=1
tcp 6 70 SYN_SENT src=212.58.172.94 dst=212.58.172.50 sport=52749 dport=180 [UNREPLIED] src=10.0.0.2 dst=212.58.172.94 sport=110 dport=52749 use=1
tcp 6 112 TIME_WAIT src=212.58.161.131 dst=212.58.172.50 sport=4049 dport=25 src=212.58.172.50 dst=212.58.161.131 sport=25 dport=4049 [ASSURED] use=1
unknown 2 582 src=192.168.100.1 dst=224.0.0.1 [UNREPLIED] src=224.0.0.1 dst=192.168.100.1 use=1
tcp 6 52 TIME_WAIT src=212.58.161.131 dst=212.58.172.50 sport=4046 dport=25 src=212.58.172.50 dst=212.58.161.131 sport=25 dport=4046 [ASSURED] use=1
udp 17 172 src=127.0.0.1 dst=127.0.0.1 sport=1025 dport=53 src=127.0.0.1 dst=127.0.0.1 sport=53 dport=1025 [ASSURED] use=1
udp 17 14 src=10.0.0.1 dst=10.0.0.255 sport=138 dport=138 [UNREPLIED] src=10.0.0.255 dst=10.0.0.1 sport=138 dport=138 use=1

Je ziet af en toe 10.0.0.2 staan dat is de exchange server.

[Verwijderd]

Hmzz vreemd. Er is niks verkeerds te vinden.

Je probeert toch wel via een computer te verbinden vanaf internet he?

[Verwijderd]

oohjah en 10.0.0.1 de terminal citrix server accepteer geen verbindingen... ik heb net even port 110 van de mail server op de linux ook als forward ingesteld op port 180 maar dan connect hij ook niet.

Maar als ik in me server zit en dan wel telnet 10.0.0.2 110 doe dan wel weer..

[Verwijderd]

Op maandag 12 november 2001 01:54 schreef nelske het volgende:
Hmzz vreemd. Er is niks verkeerds te vinden.

Je probeert toch wel via een computer te verbinden vanaf internet he?

Yep

[Verwijderd]

Op maandag 12 november 2001 01:55 schreef WilcoRADIO het volgende:
oohjah en 10.0.0.1 de terminal citrix server accepteer geen verbindingen... ik heb net even port 110 van de mail server op de linux ook als forward ingesteld op port 180 maar dan connect hij ook niet.

Maar als ik in me server zit en dan wel telnet 10.0.0.2 110 doe dan wel weer..

Dan zul je dus even het subnetmasker aan moeten passen in de maquerade regel, aangezien nu alleen verkeer vanaf 10.0.0.1 gemasqueraded wordt.

Ik zou eens met tcpdump gaan spelen op eth0 (interne interface) als ik jou was.

[Verwijderd]

Cannot connect to the Citrix Server;

The Citrix server you have selected is not accepting connections.


Als het echt fout is zegt hij dat hij de server gewooon niet kan vinden.. Maar het lijkt erop dat hij wel de server ziet maar niet erop kan

[Verwijderd]

Dus zit het probleem wellicht aan de zijde van Citrix.

[Verwijderd]

tcpdump: listening on eth0
02:57:12.879280 sv-001.router > 10.0.0.255.router: RIPv1-resp [items 1]: {10.0.1.0}(1)
02:57:27.299280 qn-212-58-172-94.quicknet.nl.3713 > sv-001.ica: S 2571434125:2571434125(0) win 6
4240 <mss 1460,nop,nop,sackOK> (DF)
02:57:28.569280 sv-001.netbios-dgm > 10.0.0.255.netbios-dgm: NBT UDP PACKET(138)
02:57:30.269280 qn-212-58-172-94.quicknet.nl.3713 > sv-001.ica: S 2571434125:2571434125(0) win 6
4240 <mss 1460,nop,nop,sackOK> (DF)
02:57:32.299280 arp who-has sv-001 tell vos.2y.net
02:57:32.299280 arp reply sv-001 is-at 0:a0:c9:ac:9d:97
02:57:36.279280 qn-212-58-172-94.quicknet.nl.3713 > sv-001.ica: S 2571434125:2571434125(0) win 6
4240 <mss 1460,nop,nop,sackOK> (DF)
02:57:42.889280 sv-001.router > 10.0.0.255.router: RIPv1-resp [items 1]: {10.0.1.0}(1)
02:57:49.409280 CDP v2, ttl=180s
DevID 'Middenmeer'
Addr (1): IPv4 10.0.0.50
PortID 'Ethernet1'
CAP 0x01
[!cdp]
02:57:52.399280 sv-002.netbios-ns > 10.0.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST;
BROADCAST
02:57:53.149280 sv-002.netbios-ns > 10.0.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST;
BROADCAST
02:57:53.899280 sv-002.netbios-ns > 10.0.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST;
BROADCAST
02:58:12.889280 sv-001.router > 10.0.0.255.router: RIPv1-resp [items 1]: {10.0.1.0}(1)


Volgens mij gebruikt citrix ook port 3713.

10.0.0.50 is een router naar een andere locatie

Heb van dit gebrabbel niet echt verstand btw

[Verwijderd]

Ik zie wel allerlei verkeer naar sv-001 (ik neem aan dat het 10.0.0.1 is) gaan op poort ica (het nummer daarvan komt niet in mijn /etc/services voor, maar zal gok ik wel 1494 zijn ).

[edit]
Ofwel de poortforwarding werkt naar behoren

Ik zie echter geen replies van de citrix machine!

[edit]
Daar zit het probleem dus

[Verwijderd]

Op maandag 12 november 2001 02:11 schreef nelske het volgende:
Ik zie wel allerlei verkeer naar sv-001 (ik neem aan dat het 10.0.0.1 is) gaan op poort ica (het nummer daarvan komt niet in mijn /etc/services voor, maar zal gok ik wel 1494 zijn ).

Ik zie echter geen replies van de citrix machine!

Klopt ja...

citrix-ica

Snap echt niet meer waarom het niet werkt...

[Verwijderd]

Kan je intern wel verbinden met de citrix machine?

En zo ja, wat geeft de output van "tcpdump -i eth0 ip host 10.0.0.1" dan?

[Verwijderd]

het kan mischien zijn dat op de 10.0.0.1 sv-001 niet de dns goed staat ingesteld. Het staat naar 10.0.0.4 Linux server maar daar draait nog geen caching nameserver op....

Hmmmzzz.... dat zou het probleem wel zijn... Kijk er op me werk straks nog wel na.. in iedere geval jullie bedankt voor de hulp.. Laat morgen wel weten of het nu goed is

[Verwijderd]

Op maandag 12 november 2001 02:16 schreef nelske het volgende:
Kan je intern wel verbinden met de citrix machine?

En zo ja, wat geeft de output van "tcpdump -i eth0 ip host 10.0.0.1" dan?

Zit daar nou niet.. Zit thuis

[Verwijderd]

Op maandag 12 november 2001 02:18 schreef WilcoRADIO het volgende:
het kan mischien zijn dat op de 10.0.0.1 sv-001 niet de dns goed staat ingesteld. Het staat naar 10.0.0.4 Linux server maar daar draait nog geen caching nameserver op....

Hmmmzzz.... dat zou het probleem wel zijn... Kijk er op me werk straks nog wel na.. in iedere geval jullie bedankt voor de hulp.. Laat morgen wel weten of het nu goed is

10.0.0.1 heeft voor NAT helemaal geen DNS nodig.

Sterker nog, aan je dump kan je zien dat NAT zoals ik hem eerder in het draadje post gewoon werkt.
Om de een of andere reden reageert de citrix machine niet, om pakketjes die wel bij hem aankomen.

Houd ons in ieder geval op de hoogte

[Verwijderd]

Op maandag 12 november 2001 02:23 schreef nelske het volgende:

[..]

10.0.0.1 heeft voor NAT helemaal geen DNS nodig.

Sterker nog, aan je dump kan je zien dat NAT zoals ik hem eerder in het draadje post gewoon werkt.
Om de een of andere reden reageert de citrix machine niet, om pakketjes die wel bij hem aankomen.

Houd ons in ieder geval op de hoogte

Zal morgen wel even vlink tegen die machine schoppen...

[Verwijderd]

Ghehehe ROFLOL

Werkt altijd Even flink de frustraties eruit gooien

[Verwijderd]

nah vindt ik zonde van de server trouwens...

Tis een p3 dual 1ghz.. met 1gb ram en raid 5 config aan diske..

[Verwijderd]

Dat noemen we een LVT server. (Leuk Voor Thuis)

[Verwijderd]

Helaas Helaas het probleem is nog steeds niet opgelost.
Wat zou het nog kunnen zijn? Iemand ervaring met dit probleem

[NiPeng]

Test eens of die server wel goed werkt.
Probeer eens een citrix sessie te maken vanuit het netwerk waar die server zelf staat zodat je de natdoos niet hoeft te passeren.

[NiPeng]

Ben even gaan zoeken aangaande ICA + NAT.
Sommige protocollen latten zich niet goed natten omdat er IPnr's ook in de data zelf staan.

Kijk hier eens:

http://www.sans.org/infosecFAQ/firewall/perimeter.htm

NAT Considerations

ICA can work with Network Address Translation (NAT), but requires some additional setup. The problem is that when the client tries to browse the Citrix server, the address returned from the server is the server?s internal address. Meanwhile, the client is only aware of what it sees as the server address, which is really the NAT translator. This problem is solved by using the altaddr /set command, which assigns an alternate IP address to the server. The address specified by the altaddr command is an external address. You must also change the client configuration to use the alternate address. Depending on the version, you must edit the Appserve.ini file for the Winframe client or add the address to the Address List option in the MetaFrame client. Additional information is available in the Citrix Solution Knowledgebase, by searching for the article titled "ICA Browsing with Firewall Address Translation (NAT)".

Denk ook aan uitgaand verkeer op de poorten boven 1023.

In de bovenste pagina wordt verwezen naar deze info van Citrix:

ICA Browsing With Firewall Address Translation (NAT)

Document ID: CTX039746
This solution pertains to:

* MetaFrame 1.8 for Microsoft NT Server 4.0, Terminal Server
* WinFrame 1.8
* MetaFrame 1.8 for Windows 2000
* WinFrame 1.7

Last modified: Tue Aug 22 13:03:27 2000


Configure the Citrix Server and Client for Address Translation


Returning External Addresses to ICA Clients

Use the Altaddr utility to configure the ICA browser server to return the external IP address to Citrix ICA Clients. The Altaddr utility sets an alternate address for the ICA browser on that machine. The external address for the server is specified as the alternate address. The Citrix ICA Client requests the alternate address when contacting servers inside the firewall. The alternate address must be specified for each server in a server farm.

To set an alternate address for a Citrix server

1. Determine the correct external IP address.

2. At a command prompt, type altaddr /set nnn.nnn.nnn.nnn, where nnn is the alternate IP address determined in Step 1.

3. Reboot.

4. Repeat on each server in a server farm.

To configure a WinFrame ICA Client to use an alternate address

1. Edit the Appsrv.ini file in the client directory.

2. Find the [TCP/IP] section.

3. Specify 1 for the UseAlternateAddress field. For example:

UseAlternateAddress = 1

4. Save the file.

The Citrix ICA Client tells the server to send the alternate address specified with the Altaddr utility.

To configure a MetaFrame ICA Client to use an alternate address

1. Open Remote Application Manager

2. Click on the Options Pull Down Menu and select Settings

3. Select the Server Location tab

4. Under Network Protocol choose TCP/IP

5. Under Address List enter the IP address of the server

6. Check the box on the bottom for Use alternate address for firewall connection

See Appendix A, "MetaFrame Command Reference," in the MetaFrame Administrator?s Guide for more information on the Altaddr utility. In addition to specifying the alternate address on the Citrix server, configure the ICA Client to request the alternate address when contacting the master browser.

Dus je past de server aan zodat deze het externe address (dus de IP van je firewall/natdoos) in de ICAdata gebruikt.

* NiPeng is geen expert

[Verwijderd]

Op maandag 12 november 2001 21:37 schreef NiPeng het volgende:
Test eens of die server wel goed werkt.
Probeer eens een citrix sessie te maken vanuit het netwerk waar die server zelf staat zodat je de natdoos niet hoeft te passeren.

Werkt correct.. in het netwerk zelf kun je gewoon citrix gebruiken

[NiPeng]

Heb je nog wat aan de info gehad?

[Verwijderd]

Kon helaas vandaag niet bij de Terminal server komen.. dat ding wordt teveel gebruikt... Dus kan er helaas weinig aan veranderen op dat moment.. Morgen avond zal ik het nog een keer proberen..

[Verwijderd]

Ik heb vandaag van alles geprobeert maar het wil maar niet lukken Dus vandaar nu maar een vlink schopje!! Wie heeft er nog een idee???..

[Verwijderd]

Nog even wat info:

Citrix geeft deze melding:
Connot connect to the Citrix Server: There is no route to the specified subnet adress

Dit geeft route aan:


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
212.58.172.0 * 255.255.255.0 U 0 0 0 eth1
10.0.0.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default Internet ip 0.0.0.0 UG 0 0 0 eth1


Eth1 is internet
Eth0 is netwerk

Citrix server zit op 10.0.0.1 En Linux server op 10.0.0.4

[Verwijderd]

~~~ Kick

[Verwijderd]

Nog maar 1 kick

[NiPeng]

Op woensdag 14 november 2001 22:39 schreef WilcoRADIO het volgende:
Nog even wat info:

Citrix geeft deze melding:
Connot connect to the Citrix Server: There is no route to the specified subnet adress

Die route komt van de client die de foutmelding geeft en niet van de linuxserver neem ik aan.

Verders weet ik het zo ff ook niet.

*bump*

[Verwijderd]

Op donderdag 15 november 2001 22:40 schreef NiPeng het volgende:

[..]

Die route komt van de client die de foutmelding geeft en niet van de linuxserver neem ik aan.

Verders weet ik het zo ff ook niet.

*bump*

Jep komt van de client.. Linux router geeft geen foutmelding.. Tuurlijk niet

[Verwijderd]

Volgens mij moet je nog wat open zetten, UDP 1604.
Stond op http://www.citrix.com/support/solution/sol00053.htm:
"The WinFrame client broadcasts UDP packets to the network with a destination address of UDP port 1604 ...."

[Verwijderd]

Nog maar 1 schopje!
Mensen het is nog niet gelukt.. nog even en ik ga een beloning uitreiken aan diegene die me kan helpen met dit probleem

Ik heb nu ondertussen alle porten van de Citrix NT server al eens geforward in me linux server maar geen resultaat..

Iemand nog tips en of idee?

[NiPeng]

Op vrijdag 16 november 2001 01:01 schreef WilcoRADIO het volgende:

[..]

Jep komt van de client.. Linux router geeft geen foutmelding.. Tuurlijk niet

Dacht vraag het maar.
Ik heb wel eens uren gewerkt aan een probleem alleen omdat ik 1 simpele vraag niet had gesteld.

Ik had trouwens echt verwacht dat die info ik gevonden had zou helpen (vooral dat stuk van "returning external addresses").