https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-netscaler
s
This message was deleted.
r
My setup is we have a SNIP for every subnet, then seperate it with VLANs, The SNIPS will create the routes in the NS routing table and will no its next place. If Traffic comes in on lets say 172.16.1.2 (NSG vServer) it will looks at its route table and send it to the SNIP. From here is where you need the Firewall Rules. The NetScaler appliance uses the subnet IP address as a source IP address to proxy client connections to servers.
Traffice comes in from Outside to DMZ NSG, NSG send it to the SNIP, SNIP will send it the SF LBVS on a layer 2 connection, SF LBVS will request a STA from DDC, NSG stores that STA.
When you add a SNIP, a route corresponding to the SNIP is added to the routing table. The NetScaler determines the next hop for a service from the routing table, and if the IP address of the hop is within the range of a SNIP, the NetScaler uses the SNIP to source traffic to the service. When multiple SNIPs cover the IP addresses of the next hops, the SNIPs are used in round robin manner.
c
By default, ADC acts like a big dumb switch. All configured IPs will ARP on all interfaces. To make it behave a little more intelligently, you need to make sure you define VLANs on the ADC - even if you are not tagging traffic sent to it. Generally you create VLANs for everything other than the NSIP network, then bind the SNIP and physical interfaces to the corresponding VLAN object. Once that's done, anything in a SNIP network will ARP out only on the associated physical network interface bound to the VLAN. When that's been done, then make sure routing is correct and firewall rules are in place.
⤴️ 3
r
Doesnt the SNIPs commuication on the NS operates at a Layer 2 to send to other SNIPs on the NS?
c
all packet steering on NS uses route table lookups unless you change the behavior via something like MAC based forwarding or esoteric nsapimgr knobs. SNIPs automatically create route table entries so while the result is generally similar, it's still technically a layer 3 decision.
r
ahh ok, I have MBF on. I see now. Thats why for us.
c
Yep, that'll do it. A lot of times MBF is enabled to unknowingly get around the "big dumb switch" design instead of carving out VLANs and populating the route table. It's not generally a huge deal but you just need to keep MBF in mind if you ever have to do something like ACLs or PBR as that can cause some unintended consequences
r
So I guess if a SNIP sends it from 10.x.x.x to SF vServer that is VIP of 11..x.x.x. Your saying if MBF is off you still need FW rules between the SNIP and the VIP?
I caved out all the VLans and serperated everthign still. Then months ago, I relize we had MBF enabled.
c
The routing process generally goes like this: - Route table lookup - SNIP on destination net? Match, packet exits via SNIP. Shouldn't need a firewall rule unless there's one inline between ADC and rest of subnet - No SNIP on destination net, but SNIP in default route network? Match, traffic exits SNIP on default route. Firewall rule would be needed if there's a firewall between this SNIP and destination net. - No SNIP on destination net, no SNIP in default route network? Dropped, no route to host.
In MBF, the NS keeps a table of interfaces that packets enter on and uses that instead of doing route lookups for each packet
this basically ensures that you reply to a host using the interface it talked to you on
r
Ok, I see now. so the SNIP still does a Lookup for the next hop to get the destintion ( Which FW will be in place for every Subnet for us)
But @sharethefixes here is my rules. I might have went over kill.
1. Outside To Public IP Source 0.0.0.0 Destination x.x.x.x (nats to 192.168.x.x) Ports Tcp/443 Udp/443 2. DMZ NS GW VIP To SF VIP Source 192.168.x.x Destination 10.200.x.x Ports Tpc/1494 Udp/1494 TCP/2598 UDP/2598 TCP/16500-16509 UDP/16500-16509 TCP/9001 3. DMZ NS GW VIP to DDCs Source 192.168.x.x Destination 10.200.x.x 10.200.x.x PORTS TCP/80 TCP/443 TCP/8080 4. DMZ NS GW VIP To Radius Source 192.168..x.x Destination Radius 10.100.x.x PORT TCP/1812 UDP/1812 TCP/1813 UDP/1813 TCP/1645 UDP/1645 5.DMZ NS GW VIP TO VDAs Source 192.168.x.x Destination 10.200.x.x PORTS TCP/1494 UDP/1494 TCP/2598 UDP/2598 TCP/16500-16509 UDP/16500-16509 TCP/9001 TCP/8008 TCP/443 UDP/443 6. Citrix Workspace/Receiver connection TO DMZ NS GW VIP Source 10.x.x.x Destination 192.168.x.x ports Tcp/443 Upd/443 7. Citrix Workspace/Receiver connection/Endpoints also known as Computers To XA-XD Source 10.x.x.x
c
You got it. The only thing that feels a bit unique is that route lookups are done on a per packet basis instead of a per connection basis, so that's why you can get in a situation where you get a SYN from a host on one interface but may see the reply exiting a different interface on ADC
r
Nescaler isnt my strong point, But I have learn alot since I was forced into it.
7. Citrix Workspace/Receiver connection/Endpoints also known as Computers To XA-XD Source 10.x.x.x Destination 192.168.x.x/10.200.x.x Ports TCP/1494 UDP/1494 TCP/2598 UDP/2598 TCP/16500-16509 UDP/16500-16509 TCP/9001 TCP/8008 TCP/443 UDP/443 8. DMZ NS GW VIP TO AD/DNS Source 192.168.x.x Destination 10.100.x.x PORTS TCP/636 TCP/53 TCP/3268 TCP/3269 9. DMZ NS GW VIP TO SF Servers Source 192.168..x.x Destination 10.200.x.x 10.200.x.x PORTS TCP/443 10. SF Servers TO DMZ NS GW VIP Source 10.200.x.x 10.200.x.x Destination 192.168.x.x PORTS TCP/443
s
Ok cool, So I think since they are thinking the SNIP is doing all the work that no port openings are needed because its like the snip on the one subnet is open to all ips on that subnet, which is basically where all the other Citrix servers are anyway, The Gateway VIP is in the DMZ VLAn on netscaler interface 0/1.
Citrix is confusing me because they say you need the ports opened to the Gateway VIP, They dont mention the SNIP. So based on what was said in the post about the SNIPS job wouldnt Citrix say you need the ports opened for the SNIP since the SNIP becomes the source IP?
In addition, If I have 2 subnets I can just put one interface to one subnet (On VLAN and the other interface on the other subnet (VLAN 2) . Then I need one SNIP per subnet (VLAN) and since the SNIP creates its routing table on creation all traffic will source and destinate between the 2 SNIPS?
c
There are two separate connections for each overall stream - client to VIP for the frontend half and SNIP to VDA for the backend. If the SNIP and VDA are on the same subnet then there shouldn't be any firewall rules necessary unless there's some kind of firewall device between NS and the rest of the subnet. Carl's got a good overview of ports needed in various scenarios at https://www.carlstalhood.com/netscaler-firewall-rules/
⤴️ 1
s
Ok cool, Thanks so much, So the 80/8080/443 from VDA to DelCo (STA service) isnt needed if on same subnet with no firewall, and if storefronts are there as well its the same, So when the Netscaler gateway sends out it actually sends through the snip on VLAn1 to SNip on VLan2 and vice versa. No 443 is needed even then, In addition when I am asked if they need to open a port to GatewayVIP or SNIP on VLan1 (DMZ) I have been saying GateWayVIP. It sounds like you are saying that the netscaler sends a request from VLan1 10.1.1.0 Gateway VIP to the storefront on 10.1.1.0 (Internal) VLan2 ----the netscaler sees the request and then sends it on from the VLan1 (DMZ) SNIP to the VLan2 (Internal) SNIP by changing the source and destination ips from the VIP and storefront to the 2 SNIPS.
Im more used to the netscalers being entirely in the DMZ
Then the ports are opened to the DMZ to an internal Subnet VLan just for the Citrix DelCos, VDAs, Dcs, StoFros
What would the "Best" way be or does it matter
Also sorry so many questions but No Routes need to be added if there are SNIPS on each Subnet correct?
r
The reason they dont say SNIP is because of many different load balancers and vendors. If on the same subnet then yes no firewall. We have Interface 0/5 and 0/6 in the DMZ with a VLAN set and taggeg with LA/1 With a SNIP for the DMZ. internet sends it to the DNS name, Which will reolved to the DMZ NAT, then sends to the DMZ NSG vServer , which will do a lookup for the SNIP on the SFLBS which then send it to the SFLBS VIP ( Frontend) which then sends it to the DDCs. If you add SNIPs it will update the routing table. But @CTXMike is way stronger at the networking than me 🙂. All this can make your brain hurt
If it was me, I would seperate the interface for DMZ and LAN. Thats me though. I do 2 10g SFP+ for Lan, and 2 1gpbs with a linked aggerated setup
We have a MPS 8500 thoug. SDX can do way more
s
no need to add route 10.0.0.0 10.1.1.1
in CLI i meant
Ok I think I get it,. If I say to my network guys Open port 443 (10.1.1.20 StoFro1) in/out (10.0.0.50 Netscaler Gateway VIP (DMZ)) Then they ask me what about the SNIP (10.0.0.51)?
It doersntr need the SNIP
because the route changes the destination ips so it still thinks 10.1.1.20 and 10.0.0.50 are communicating on port 443
Its really more about how to tellthe network teams in various companies what ips need what ports
Then always ask "What about the SNIP
I think it does this someone correct me if im wrong (Some chu mp in starbucks goes to MyCompanyCitrix.Company.com > 33.65.87.90 > NATs to Netscaler GateWay VIP 10.1.1.50 in DMZ (Interface 0/2) on subnet 10.1.1.0 Vlan1.
After the LDAP the Session policy says go to my Store URL at 10.2.2.20/Citrix/StoreWeb (Internal -Interface 0/1 on subnet 10.2.2.0 Vlan2). The VIP sees it has a SNIP 10.1.1.51 and the SNIP then is actually behind the scenes saying Packets from GWVIP 10.1.1.50 > destined for 10.2.2.20 443 need to go through my routing table that says Hey 10.2.2.0 you have a SNIP too!-Sweet Im sending this traffic to you 10.2.2.21 from 10.1.1.51 but we will pretend that the source is still the VIP gateway and the destination is still the StoFo1 10.1.1.20.
Thenthe SNIP on the 10.1.1.21 does the same sending it to the Storfront.
So do the SNIPS use their own ports to tunnel traffic? (Probably not since its all internal to the netscaler like a dummy switch) it just ends up on the other side
c
frontend and backend are always completely separate connections
The client will always and forever only talk to the VIP. Anything that happens behind the scenes is sourced from SNIPs.
So for frontend connections to the gateway, the only thing that has to be open between gateway vip and clients is tcp/443 and udp/443.
All communication between the NS and storefront/VDAs/etc is between the appropriate SNIPs as source and backend server as destination.
Initial access: User talks to VIP Auth: SNIP talks to LDAP/RADIUS/etc Enumeration: SNIP talks to storefront Session launch: SNIP talks to VDA All communication is subject to route table lookups in this order: 1) destination owned by ADC -> Destination is a VIP -> accept traffic, but keep in mind route table is used for response 2) Destination not owned by ADC -> SNIP on destination subnet -> use that SNIP 3) Destination not owned by ADC -> No snip on destination, SNIP on default route subnet (0.0.0.0) -> use that SNIP 4) Destination not owned by ADC -> No SNIP on destination subnet, no SNIP on default route subnet -> traffic dropped If you only ever access resources that are on directly connected networks, and there are no firewalls between you and those networks, then you have no firewall rules to open. If you access resources on networks you are not directly connected to, that traffic will be sourced from whatever SNIP resides in the same subnet as your default route (0.0.0.0). If your default gateway is itself a firewall interface - or passes through a firewall at any point on its way to the backend resources - then and only then do you need to configure firewall rules.
r
Yea thats real good CTXMIke
10 Views
Open in Slack
PreviousNext
Powered by